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.)
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? 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. 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. > On 8 Jan 2018, at 01:24, Alex Miller <[email protected]> wrote: > > >> On Sun, Jan 7, 2018 at 6:53 PM, Nathan Fisher <[email protected]> wrote: >> >> I strongly agree with your decision of “pick the latest”. While I do >> understand multiple active versions can make it easier for a developer I >> don’t think that’s the “right” decision. Besides I can only imagine how much >> of a pain it would be to implement reliably. I’d expect if I specify a >> patched version of struts that a transitive dependency wouldn’t have the >> ability to override that for its own purpose. > > I guess I didn't mention that top-level deps always win, so if desired you > are always able to decide the specific version in your project. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to [email protected] > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
