Fork me on GitHub
#boot
<
2017-02-28
>
richiardiandrea00:02:47

can't I call System/setProperty in a pod? -> clojure.lang.ExceptionInfo: java.lang.ClassNotFoundException: System.setProperty, compiling:(boot_dynamodb/pod.clj:51:5)

micha00:02:14

can you paste how you're calling it?

micha00:02:36

it's 2 args, both strings

richiardiandrea00:02:22

probably a stupid error:

(defn- set-sqlite-native! [sqlite-native-dep]
  (let [sqlite-resolved-path ^String (pod/resolve-dependency-jar pod/env sqlite-native-dep)]
    (util/warn "Sqlite4java resolved to %s\n" sqlite-resolved-path)
    (System/setProperty "java.library.path" sqlite-resolved-path)))

richiardiandrea00:02:29

Ah, I suspect the returned value of resolved-dependecy-jar is nil maybe

micha00:02:39

it might be a URL

micha00:02:02

or a File or something

richiardiandrea00:02:16

thanks let me see

codemartin05:02:45

Hi! I'm compiling a boot cheat sheet, and am wondering if there is something like Leins :injections in boot? Basically it evaluates a form into every ns, which is useful when having something that should only be run in development (as it is not included when making a jar/uberjar)

richiardiandrea05:02:47

@codemartin there are similar things: 1) a file called `boot-shim.clj can inject anything, see at the bottom of https://github.com/boot-clj/boot/wiki/Configuring-Boot

richiardiandrea05:02:27

2) there is -i option to boot directly for evaluating any form

richiardiandrea05:02:53

3) there is a -e iirc to repl as well

dm310:02:02

I use ~/.boot/profile.boot and im.chit/lucid.core.inject for repl-enrichment

pleasetrythisathome17:02:21

hey! i’m having an issue with namespaces being in :source-paths while running my test suite

pleasetrythisathome17:02:06

not quite understanding why that’s an issue with the classpath, is boot not loaded into the pod running the tests?

micha17:02:17

the pod does not have access to the boot.core namespace

micha17:02:24

but boot.pod is available there

pleasetrythisathome17:02:39

does that mean i can’t have tasks that compose boot.core tasks anywhere in source-paths?

pleasetrythisathome17:02:49

or should i be resolving them in the tasks

micha17:02:02

yeah you want to do all of that in the core pod

micha17:02:10

the one the build.boot is evaluated in

micha17:02:42

you can't compile namespaces that refer boot.core in other pods, because that namespace won't be on the classpath

pleasetrythisathome17:02:42

currently i have a separate build.clj file in a repo that has tasks that i use across a number of personal projects

pleasetrythisathome17:02:53

and i’m using it as a submodule

pleasetrythisathome17:02:11

instead of a checkout dep, because it changes frequenctly and i find it more convenient (maybe)

pleasetrythisathome17:02:41

so at the top of built.boot i add that dir to :source-paths

pleasetrythisathome17:02:22

which is a problem for other pods because i want to use boot.core stuff in that file

micha17:02:37

you shouldn't need to do anything with boot.core in other pods though

pleasetrythisathome17:02:26

right that’s true, but it’s currently being loaded at the top of my build.boot, can i remove it from source-paths before other tasks?

micha17:02:59

you can do that, but it seems unnecessary

micha17:02:21

its presence on the classpath is a problem?

pleasetrythisathome17:02:31

because it’s requiring boot.core

micha17:02:37

usually things can be on the classpath as long as you don't require them

micha17:02:50

yes but why is that namespace even being compiled in the pod?

micha17:02:10

it should just be a random file on the classpath that you can safely ignore

pleasetrythisathome17:02:10

it’s being required in build.boot

micha17:02:19

build.boot is not available in that pod

micha17:02:44

unless you explicitly do (load-file "build.boot") and evaluate that in the pod

pleasetrythisathome17:02:44

h/o let me investigate

micha17:02:13

it could be that the test machinery is finding the clj file on the classpath and looking in there for things to test

pleasetrythisathome17:02:50

yea that’s possible

pleasetrythisathome17:02:07

is there a good way to figure out exactly why a file was loaded?

micha17:02:33

the stack trace may have some useful info?

pleasetrythisathome17:02:17

this problem would also be fixed if i packaged this is a jar instead of included it in :source-paths right?

pleasetrythisathome17:02:50

sounds pretty likely that boot-test is finding the ns in source-paths and looking for tests

pleasetrythisathome17:02:27

packing the tasks as a jar solves the issue

pleasetrythisathome17:02:41

but seems like sidestepping the problem

micha17:02:43

@pleasetrythisathome you can exclude those namespaces from the tests

micha17:02:47

if you want to do it that way

pleasetrythisathome17:02:32

tried adding it to (task options! test {:exclusions #{‘pleasetrythisathome.build}))

pleasetrythisathome17:02:38

but still had the same issue

pleasetrythisathome18:02:40

hmm that’s odd, it works if i set task options in built.boot but not if i do it inside the task

hiredman18:02:00

how does one disable boot's new version check thing?

hiredman18:02:39

or whatever is causing a stacktrace with " at Boot.download(Boot.java:173) " while s3 is down

pesterhazy18:02:59

--offline maybe?

micha18:02:22

it shouldn't check for a new version of boot

micha18:02:44

it only does that when it doesn't already have the version of boot you specify

micha18:02:09

if you do BOOT_VERSION=2.7.1 boot ... you should avoid the downloading

micha18:02:20

or whichever version of boot you have locally already

hiredman18:02:31

gah, I think this is just what I get for using docker, my testing docker container does the check, but I can't build a new docker container with everything updated to not do stuff with s3 because all the artifacts to build from are on s3