This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-31
Channels
- # adventofcode (1)
- # beginners (24)
- # boot (10)
- # cider (3)
- # cljsrn (11)
- # clojure (83)
- # clojure-dev (8)
- # clojure-russia (1)
- # clojure-spec (6)
- # clojure-uk (3)
- # clojurescript (25)
- # cursive (6)
- # datomic (7)
- # docs (1)
- # emacs (5)
- # hoplon (14)
- # jobs (1)
- # luminus (1)
- # off-topic (13)
- # om (3)
- # onyx (10)
- # parinfer (3)
- # re-frame (1)
- # ring-swagger (1)
- # sql (1)
- # unrepl (62)
trying to think through the best way to handle mutli-module style projects with boot... right now i have a working solution, but it relies upon a lot of global state stuff via set-env! since Pods don't seem to care about :source-paths. this approach makes it impossible to chain builds of different modules in one boot invocation though since, afaik, once something is added to the core pod's source-paths removing it doesn't then remove that from the classpath. should I be doing this some other way, perhaps via the normal fileset flow? but even then there's only one fileset per run and i also haven't found a way to directly run tasks within pods, just functions and such.
@tdavis there is boot.parallel for multiple boot executions but no batteries included option for now that I know of (others might have better ideas)
hmmm... interesting. so if i wanted to build all the sub-modules in a task i could potentially use runcommands or compose runboot. any thoughts on how that would work with, e.g., target if i wanted to get multiple jars into the target folder? would i just put that last in (comp (runboot ...) (runboot ...) (target)) and it would Just Work ™️
Concurrency control is completely in your hands so the target will be written not deterministically by multiple threads and therefore might end up being a mess 😄 Filesystems do not lock and I don't think target does it for you, but I never tried...Probably the fileset files are written in their own .cache folder actually and not interleaving but then the target task needs to copy them over...which one will it pick?
Sorry I am thinking aloud here, I don't have an answer...thinking of it a little bit more, target takes whatever is on the fileset and dumps that. So the lock should be on the fileset...which saves files using timestamps + hash... probably I would try first and if it does not work check how the fileset is reconciled from parallel tasks, sorry I don't remember that 😉
So it seems runcommands would be also worth checking. The ns boot.test is an example of how to use it
No problem! Boot commands with a target at the end for each individual project might work. I would no venture for concurrent runs on the same project though
Does anyone have any ideas on how I can manage dependencies for multiple outputs of a single project? I want all dependencies to be present when developing (autocomplete in Cider), however when building the jar, I don't want deps from other components included.
I've briefly looked into deps.edn and the boot task that handles that, however I can't seem to get it to work properly. (It ends up looping through loading dependencies endlessly)