Fork me on GitHub
#boot
<
2016-10-11
>
limist11:10:44

Hi all: I recently upgraded from using Boot 2.5.5 to 2.6.0, and saw that when running tests for one of my libraries, the :resource-paths (as defined in the library's build.boot file) is no longer visible/defined, the process barfs with NPE when it's supposed to load files there. Reverting back to Boot 2.5.5 works ok. Any ideas? Checked https://github.com/boot-clj/boot/blob/master/CHANGES.md but didn't see anything pertinent to this problem...

martinklepsch11:10:31

@limist have you tried with creating a new dir, with a file in it and then doing

boot -B -r that-new-directory repl
;; then in the repl try
(slurp ( "that-file.txt"))

martinklepsch11:10:07

The -B prevents your build.boot from being evaluated, the -r adds the directory to your resource paths

limist12:10:00

@martinklepsch Thanks, the code you suggested works fine, using Boot 2.6.0

martinklepsch12:10:43

can you provide your build.boot (maybe in private if you prefer that)

limist12:10:05

OK, will do, thanks.

limist15:10:14

@martinklepsch Thank you for the detailed help!

richiardiandrea18:10:32

oh cool, if standalone might be worth maybe putting it in https://github.com/boot-clj/boot/wiki/Snippets

flyboarder18:10:47

im working on a generic express server that can be auto included so you can build electron hoplon apps

flyboarder18:10:25

then I will tackle a nodejs port of castra 😛

richiardiandrea18:10:27

I heard those are fun to work with, I guess you can confirm that

flyboarder18:10:56

yeah i havnt played with nodejs too much other than cli apps, so this will be interesting

mikebelanger18:10:28

@flyboarder cool — so you could essentially build an electron app along with Hoplon?

flyboarder18:10:05

right the idea is that hoplon does it’s thing as per usual, you just also get the option of launching it via electron just by adding the task

flyboarder18:10:28

it works on my demo app, but nothing production yet

mikebelanger19:10:55

@flyboarder I’ve seen other electron-targetted cljs, but iirc not as simple as just adding a boot task, and it also has hoplon. Seems like a good idea

flyboarder19:10:58

yeah I decided that the investment into running hoplon cross platform was well worth it

donaldball19:10:33

Hi boot friends. I’m using boot to build a couple of executable jars from a repo. Currently I have a build-client and a build-server task, which I combine into a build task with comp. Of course this doesn’t exactly do what I want because the second build winds up containing the first. Is there an idiomatic way to tell boot to run two independent tasks, either serially or, ideally, concurrently?

micha19:10:45

@donaldball you can run boot inside of boot to accomplish this

micha19:10:50

the idea there is that you have one build.boot which is used in that example in 3 boot instances

micha19:10:02

there is the alpha task that builds module alpha

micha19:10:12

and the bravo task that builds the bravo module

micha19:10:48

there is the doit task that is the one that starts nested boots to build alpha and bravo

micha19:10:38

also in that example there is a dependency relationship between alpha and bravo: bravo depends on alpha

micha19:10:43

you may or may not need that

donaldball19:10:17

cool, I get the gist

micha19:10:40

without the dependency relationship you probably don't need the semaphore

richiardiandrea19:10:31

silly question, I would like to use two sounds for notify and I put them in resources/boot/notify/. Should it be enough then to use -T themename ?

richiardiandrea19:10:05

I also tried boot watch test -f backend notify -a --soundfiles '{:failure "resources/boot/notify/music_failure.mp3" :success "resources/boot/notify/music_success.mp3"}' without success

micha19:10:29

is "resources" on the classpath?

micha19:10:36

seems like that should work

donaldball20:10:31

boot repl isn’t giving me a repl with any of my project’s dependencies loaded…?

micha20:10:27

@donaldball how do you mean?

donaldball20:10:27

Just as I say. In my build.boot I declare a normal dependencies vector via set-env! which I would expect to be loaded when I run boot repl, but I’m not seeing any of them, including the specified clojure version

donaldball20:10:04

I can replicate with just about the simplest possible build.boot:

donaldball20:10:06

(set-env!
 :dependencies '[[org.clojure/clojure "1.9.0-alpha12"]])

donaldball20:10:16

which suggests I’m misunderstanding something fundamental and simple 😛

mynomoto20:10:20

@donaldball : clojure version depends on your boot.properties file locally or on ~/.boot

mynomoto20:10:01

You can check that with boot -V

donaldball20:10:06

Thanks, that was my error

richiardiandrea20:10:10

@micha yes I can slurp it...weird, I'll dig

micha20:10:36

@donaldball you will want to have an explicit clojure dependency even though clojure is already loaded. this explicit dependency will control how transitive dependencies are resolved in the aether maven machinery

micha20:10:09

like if you have other dependencies that depend on clojure of different versions

micha20:10:45

the dependency resolution machinery doesn't know that clojure is already on the classpath, so it will try to pull it in as a transitive dependency

micha20:10:06

unless you provide your own explicit clojure dependency version

donaldball20:10:21

got it, thanks

donaldball20:10:13

Speaking of aether, I just crashed on the shoals of jackson version conflicts away with the very latest s3-wagon-private

donaldball20:10:37

Has anyone run across a wagon impl that just shells out to the aws cli to do the work?

micha20:10:52

@donaldball have you tried the org.springframework.build/aws-maven one?

micha20:10:25

not good?

donaldball20:10:43

doesn’t permit the use of sts credentials; hard requirement for us

donaldball20:10:16

I have forked it to work with a good combo of amazon+jackson, but that doesn’t work with the boot worker pod implicit dependencies

micha20:10:58

perhaps we can update the worker pod's version of jackson

donaldball21:10:37

2.5.5 is what s3-wagon-private now uses, or will when they release 1.3.0

micha21:10:10

maybe it doesn't really need that version

micha21:10:44

i guess you probably tried excluding jackson when you load the wagon dep?

donaldball21:10:30

it needs it; the amazon lib has a hard minimum requirement

arohner21:10:08

I’m running boot repl, and then from inside the nrepl, (boot (cljs)). Everything works, except that CLJS compile warnings/errors go to the terminal, rather than my nrepl output. Is there a way to fix that?

danielsz22:10:46

FYI, I've deployed a snapshot of system with a surprise feature. Lisp mode, recompile only (no usage of remove-ns ). Basically, this gives you a standard Lisp REPL experience where you recompile until it breaks. 😃

danielsz22:10:42

As usual, available from Clojars. Repo is here: https://github.com/danielsz/system

micha23:10:49

whoa @danielsz that sounds sweet