Fork me on GitHub
#boot
<
2017-04-03
>
juhoteperi14:04:28

Next boot-cljs will have refactored compiler option handling which should support user provided values for every option, but provide defaults like previously: https://github.com/boot-clj/boot-cljs/blob/master/docs/compiler-options.md

juhoteperi14:04:45

I'll probably write another doc about how to serve Cljs compiler artifacts from filesystem, instead of classpath

juhoteperi14:04:56

And maybe I'll write blog post about this also as this is the reverse of what I have recommended 😄

Joe R. Smith14:04:08

How can I pass the absolute path of a file to a boot task (from another boot task using with-pre-wrap to get at the fileset). It doesn’t seem like boot tasks can/should be called from within a with-pre-wrap. I’m trying to use boot-exec‘s exec task, but the command-line process I’m trying to call needs the absolute path to some files in my fileset. 😕

juhoteperi15:04:01

When you need to run external application from boot task (inside the middleware, with-pre-wrap), you should probably use boot.pod/sh instead: https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/util.clj#L456

juhoteperi15:04:39

Tasks are not supposed to be used from inside other tasks

juhoteperi15:04:53

Though boot.pod/sh obviously wont take care of setting up pwd and adding output files to fileset

juhoteperi15:04:25

It has three parts: 1. Copying necessary input files from fileset to temp dir 2. Running the commands inside the temp dir 3. Copying interesting files from temp dir to fileset

seancorfield16:04:26

I’ll re-raise my Q from yesterday, now there’s more eyes in the channel: If I specify -d on the command line, it doesn’t seem to pick up :repositories from ~/.boot/profile.boot (so it doesn’t find artifacts that aren’t in Central/Clojars). Is that expected behavior?

seancorfield16:04:43

(and that’s outside a Boot project folder)

seancorfield16:04:32

And, as noted yesterday, if I do boot repl instead, that does pick up ~/.boot/profile.boot because I can merge-env! in that dependency and it finds it just fine.

micha20:04:40

@seancorfield that isn't ideal behavior, i think it should respect repository settings in build.boot

seancorfield20:04:43

@micha To be clear: this is in the absence of build.boot — but it didn’t seem to run ~/.boot/profile.boot which surprised me a bit.

micha20:04:02

ah yeah that also

micha20:04:27

handling the -d option properly is a little tricky

seancorfield21:04:29

It just means you can’t easily just start a REPL with dependencies that come from non-standard repositories. Worth a note in the Boot docs I think.