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 :dependencies
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?
Yeah. In that case, will weird stuff happen from two different dependencies?
So maybe I should do a filter
to remove the already existing dep?
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.
Is :provided
generally used in the clojure dependency to avoid complexity here?
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
What do you mean by :scope "provided"
conflicts?
Is there a boot equivalent of the :dev
profile? Would like to add resource paths, source paths, etc. only when testing or REPLing.
@aengelberg: See https://github.com/boot-clj/boot/wiki/Boot-for-Leiningen-Users#profiles-middleware
basically use tasks that modify the env as you wish
@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?