This is excellent news! Thank you very much! On Monday, September 21, 2020 at 7:39:25 PM UTC-7 Alex Miller wrote:
> 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/d50d04fc-43af-4b71-84c7-62415683e605n%40googlegroups.com.
