lein plugin does not generate .lein-env but setups environment directly

[darwin]

The problem with generated .lein-env is that it does not play well with more advanced project.clj setups where one would like to run multiple lein tasks in parallel or use different lein profiles with different env settings. Currently, the last task "wins" (or .lein-env could get potentially clobbered).

This is just a proposal which works for my scenarios. It relies on the fact that shell-command is called for all java-related compilations (including clojurescript) and we can modify init form to set environment directly. I'm unable to reason about its full correctness under all circumstances because I'm not an Leiningen expert. I would like to discuss it here.

[weavejester]

This seems like it could be fragile around trampolining, and perhaps other Leiningen functions. Is this just trading one set of problems for another? Also, using an atom seems like it might cause issues for parallel Leiningen build chains, such as in lein pdo.

[darwin]

Yes, I agree that this could be fragile. Maybe someone could come up with a better solution.

I don't like the env capturing in atom at all. Would be great if that information could be obtained safely in shell-command hook somehow.

[brianru]

What about adding a PID suffix to the file?

I just ran into this issue, though the fix I'm going with is to use separate environment variables for each of the builds we're running in parallel. Which makes sense for my use-case as I'm building different services from one mono-repo, but may not make sense for other use-cases.

[weavejester]

I don't think there's a platform independent way of getting the PID in Java, unfortunately.