These changes are in the new 1.10.1.693 prerelease of clj if you want to test it. Assuming things look good, I'll promote that to a stable release soon.
In this release, things will be ordered :extra-paths (in order, if used), then :paths (in order, if used), then libs. That reverts the changes in the release that led to the issue here. Additionally, libs are now sorted by tree depth (roots first, then their deps, etc), then alpha per depth so this should greatly improve reproducibility of lib ordering across builds. On Monday, September 14, 2020 at 7:51:07 AM UTC-5 Alex Miller wrote: > Just FYI, we have a plan to address this and it should be in the next > stable version. > > On Sep 14, 2020, at 1:00 AM, 'bed...@yahoo.com' via Clojure < > clo...@googlegroups.com> wrote: > > > > I couldn't agree more. > > It really boils down to the simple fact that class loading in the JVM - > for the standard classloaders - is well-defined. > > If a build tool is not able to reflect this, it is an unreliable build > tool. It doesn't matter if anyone thinks CLASSPATH order shouldn't matter > from a philosophical point of view. (And inconveniencing deps.edn users to > go tell the authors of dependencies to "fix their resources" is not a > realistic approach) > > Providing dependencies in an unsorted map like deps.edn is doing now is > inherently unstable. > That doesn't necessarily make deps.edn unusable, but - as others have > pointed out - a source of surprising errors. > Until an order is defined that survives changing OS/JVMs, I will advise > anyone to not use deps.edn. > > Furthermore, all build tools - with the exception of Bazel and derivates - > do rely on transitive dependency resolution and thus also are inherently > fragile. > But either through established practices or defined standards: they offer > a way to define an order should conflicts arise. > (Take a look at https://issues.apache.org/jira/browse/MNG-1412 again for > a longer discussion). > > At the very least: The location of your own classpath entries must be > well-defined. They are by default first on regular CLASSPATH. > I wasn't following the latest development on this, but I would assume that > is a reasonable demand and has been fixed in newer tools.deps versions? > > Thanks, > Jochen > > On Sunday, September 13, 2020 at 8:37:31 AM UTC-7 Matching Socks wrote: > >> Too fragile. This reminds me of the notion of "situated programming", >> featured in the talk by Rich Hickey: you and your programs operate in the >> middle of a bizarre and changing situation. For Clojure, the Java >> ecosystem is part of that situation. Even if some jars do not overlap >> today, you will be forced to take a minor update someday that introduces a >> clash. Or perhaps (quite likely) jars do overlap today, but you will take >> a minor update someday that causes the classpath to emerge from the >> hash-map differently and your program won't work anymore. The insight of >> the theory of "situated programs" is, not to hit a cliff when a perfectly >> legal quirk arises in the situation. >> >>> -- > > 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 > 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 > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/WI3ddZRK4Bg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+u...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/e229b29e-304d-4e96-bf26-59b255e3920bn%40googlegroups.com > > <https://groups.google.com/d/msgid/clojure/e229b29e-304d-4e96-bf26-59b255e3920bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/5af9b933-ad9a-413f-96cb-3350dfaf7990n%40googlegroups.com.
