On Monday, January 8, 2018 at 2:47:23 AM UTC-6, Gary Verhaegen wrote: > > Have you considered adding an equivalent to lein’s pedantic option, i.e. > an option that would die on ambiguous versions rather than make a choice, > thereby forcing users to make that choice explicit as a top-level entry? > (Or through exclusions etc.) >
Eventually, maybe. I don't see that ever being the default though. > As an aside, is it even possible on the JVM to have multiple versions of a > dependency loaded? Wouldn’t the last version loaded override all the common > classes, leaving you with a sort of hybrid that doesn’t correspond to any > single version? > Actually the way things work the *first* version on the classpath is the one that will be used. Having more than one version of the same lib on the classpath is almost certainly a bug, not a feature. > I’d really like a dependency system that makes each dep’s transitive > dependencies only visible to itself, so there would never be any reason to > resolve dependencies. > You need classloader support for this and indeed this is what OSGi and some early versions of the Java module system do. Working in that kind of environment is very constraining. A lot of discipline is required with respect to your interfaces between loaders and in general I think it's way too much of a burden to use as the normal operating mode (which is one reason you don't see it in the Java module system of java 9). It is a good option for systems where you want users to plug in functionality and the scope of those interface points is small and highly controlled. > Also, how realistic do you think it is today to expect all of our > transitive dependencies to be developed according to that growth mindset > you mention? It’s one thing to adopt it in my code, but quite another to > assume it’s followed correctly by all of the underlying Java libs. > I think it's unrealistic, but you already live fully in that world. mvn, lein, boot, gradle, sbt, ivy etc - all dependency resolvers in the Java ecosystem already do exactly what I've described above with choosing Java dependencies. Ususally it works, sometimes it fails and manual nastiness is required to resolve the issues. The "growth not breakage" mindset is the way *out* of that problem - where to start if not in our own code? -- 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.
