Howard, thanks for posting that library. I've passed on the info to some of the other developers at work. That kind of tool is highly valuable, I'll likely start using it soon.
Gary, the MrAnderson approach sounds similar to shading; I'll take a look today. Stuart, the most common approach boils down to trust and hope, and I don't think it's good enough. As projects grow larger the likelihood of running into incompatibilities also grows, regardless of community etiquette. Thank you for suggesting :pendantic. On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship wrote: > > 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.stua...@gmail.com > <javascript:>> 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 clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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.
