We have some very, very complex projects that bring in boat-loads of dependencies, some of which will have version conflicts, if left unchecked. I've created a Leiningen plugin, vizdeps, to make it easier to see the artifact tree, identify and repair conflicts, and determine why any particular artifacts are in the build.
https://github.com/walmartlabs/vizdeps On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > This is a well-known problem in the JVM world, not just Clojure. > > The most common approach is: Always use the latest versions, and don't > break backwards-compatibility. > > Most open-source Java and Clojure libraries are careful about not breaking > backwards-compatibility. So in general, you're safe choosing the latest > version of any library. > > Leiningen has the `:pedantic` option which can be set to warn or fail when > there are possible dependency conflicts. > > Neither Clojure nor the JVM has explicit support for linking to specific > versions of a library. Work-arounds exist, but they often increase overall > complexity and lead to conflicts which are harder to debug. > > –S > > > On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote: >> >> Hello All, >> >> >> I have a general inquiry regarding conflicting dependencies in >> Clojure projects and how they affect applications at runtime. I believe >> this is a common problem faced by many languages in this day and age where >> we try not to reinvent the wheel by depending on the work of others. >> Basically: my application depends on libraries *A*, *B*, *C*, and *D*. >> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us >> depend on *different versions* of library *A.* Leiningen thankfully >> warns us in many of these situations by suggesting exclusions. However, how >> can I possibly know that something hasn't broken? Stringent testing can >> give a certain degree of confidence that things are still working, but it >> would seem to me that to ensure correctness, we should include *all* versions >> of the dependencies and have the functions link to their respective >> *versioned* identites. Does anyone have advice on how they solve these >> kinds of problems on their codebases in the wild? Thankfully nothing has >> broken yet (to my knowledge), but it seems we have very few assurances here >> and the best we can do is *hope* nothing is broken. Any advice is much >> appreciated. >> >> Thanks, >> >> Arthur >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Howard M. Lewis Ship Senior Mobile Developer at Walmart Labs Creator of Apache Tapestry (971) 678-5210 http://howardlewisship.com @hlship -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
