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

@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!