This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
What's the recommended way to start up a pod that uses a different version of Clojure than the parent environment?
@aengelberg: you can set a dependency on
org.clojure/clojure in the pod's env
What if there is already a version of clojure in the parent environment? If I
conj a new one onto the end, does that overwrite it?
you mean if you conj
[org.clojure/clojure "1.6.0"] onto
[[org.clojure/clojure "1.7.0"]] for example?
like libraries detecting clojure version by looking for certain inner classes on the class path
Slightly related question, what if project A has dep vector
[[project-B "1.0"] [org.clojure/clojure "1.7.0"]] and project B has dep vector
[[org.clojure/clojure "1.6.0"]]? Which clojure jars will be fetched?
I believe that leiningen lets project A override the clojure dependency in this case.
i mean when you have a dependency in your project that is of scope provided, when you start boot it will fetch that dependency
however it will not be fetched transitively when your project is included as a dependency in another project
I think that makes sense. I'm writing a plugin that's like cljx, so it has a clojurescript dependency in only the test scope. Also, the consumers of this plugin are libraries aiming to be backwards compatible with earlier versions of Clojure. So it helps to understand the Clojure dependency magic so I know how to best structure this project.
the unfortunate thing is that there isn't a good way to handle
:scope "provided" conflicts
at least if you declare the transitive dependency people can debug conflicts using the normal methods, like
lein deps :tree or
boot show -p
Is there a boot equivalent of the
:dev profile? Would like to add resource paths, source paths, etc. only when testing or REPLing.
@aengelberg: with respect to the profiles, what tasks would you be running when you wouldn't want those resource paths, source paths etc on the classpath?