Clojurians Log v2
boot
@donaldball if you can’t do that, you might be better off using https://github.com/clojure/tools.cli directly
@donaldball you could have the tasks read defaults from an atom + one task to write to that atom
@seancorfield Thanks for your advice. It turned out to be that private repo authentication was added to tools.deps since boot-tools-deps was last updated. I've put together a PR here: https://github.com/seancorfield/boot-tools-deps/pull/23
Hi all: just following up if anyone has any feedback about when it's safe to set the boot environment. Setting the boot env at task construction time is a pretty standard pattern:
(deftask task
[]
(set-env! ...)
(comp (task-1) (task-2) ...))
(deftask task
[]
(comp (load-env :env env) (task-1) (task-2) ...))
load-env task to work properly. Have you seen this pattern? Would you expect it to work?
@zalky can you share the load-env task?
Yeah, thanks for the response! This is what I have right now, though I've tried variations on it:
(deftask load-env
[e env ENV code "Environment map"]
(with-pre-wrap fileset
(->> env
(apply concat)
(apply set-env!))
(commit! fileset)))
@alandipert, thanks again for the response! I was able to try your suggestion out this morning but it produced the same result as the first versions of the task.
Interestingly, the environment appears to change, but the change is not producing intended effect in the system.
What I'm actually doing is adding some source directories as :resource-paths to the environment, and then installing my project as a jar to the local maven repo. However the source never shows up in the resulting jar.
When I load the :resource-paths at task construction time, everything works as intended, so I'm pretty sure the rest of the pipeline is correct.
Ah, I think I figured it out! So it was the environment map itself that was the problem. Instead of providing a fn to update :resource-paths, I was just passing in a value for :resource-paths. At execution time, this overwrote important changes that downstream tasks like pom had made at construction time.
Hmm, I'm now thinking this pattern is problematic because there's no guarantees about how downstream tasks are using the environment. They may do important things at construction time based on a partially configured environment.
After some more digging, I don't think it was the overwriting... I'm kind of stumped.
Thanks @cbowdon -- 0.4.6 released to Clojars with that PR merged in!
Thanks!
hm, that looks like it should work, but it does some unnecessary things
(require '[boot.core :as core])
(core/deftask load-env
[e env ENV code "Environment map"]
:pre [(map? env)]
(core/with-pass-thru _
(doseq [[k v] env]
(core/set-env! k v))))
(core/deftask show-env-key
[k key KEY kw "Environment key"]
(core/with-pass-thru _
(println (str "key = " (core/get-env key)))))
(core/deftask foo []
(comp (load-env :env {:foo 123})
(show-env-key :key :foo)
(load-env :env {:bar 321})
(show-env-key :key :bar)))
that seems to update the env at the right time so that subsequent task handlers see the updated env, if i understand your intent correctly
Just FYI (mostly for @alandipert) this issue is happening more frequently now https://github.com/boot-clj/boot/issues/715 (specifically the dynapath syntax error) and it's making Boot virtually unusable for us now.
It's happening on maybe three out of four runs of our test suite, as the pods are being initialized (so, asynchronously and early in the process as our Boot pipeline spins up).