<div dir="ltr">Indeed, the problem is present in popular languages used to write big systems comprising hundreds of dependencies and thousands of packages (namespaces). That is, Java, in my experience. The build system (Maven) does nothing to mitigate it; you have to resolve conflicts manually.<div>Sometimes a very commonly used utility library's API is updated in a backwards-incompatible way. In a big project, both versions of the API are likely to be present due to transitive dependencies. You know how do they (the community) address this issue? They rename packages appending a version number. Look at Apache Commons Lang, for example (<a href="https://commons.apache.org/proper/commons-lang/">https://commons.apache.org/proper/commons-lang/</a>). And, the library maintainer has to do it, or the users of the library have to fork it and maintain their fork. At least, in Lisp we got rename-package, so that the library user <i>can </i>provide their alternative package names, even if it's not always the most sensible thing to do.</div><div>And that only might cut it with utility libraries. In general, you cannot use together two versions of a web framework, ORM, dependency injection container, or any other important piece of your architecture.</div><div><br></div><div>Nobody expects Java to fail because of that or to ever fix the problem. Nobody thinks the Java community is hostile if they say "we do it manually, deal with it". (Actually, there <i>is </i>a solution in Java for that problem, it is called OSGi, and I can assure you that it requires more manual fiddling and it causes more headaches than the problem it is supposed to fix).</div><div><br></div><div>Yes, that sucks. But not <i>that</i> much. Yes, one always expects Lisp to be better and to solve all of the world's problems. Sometimes it doesn't. But it's still great ;)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 May 2016 at 09:58, Hans Hübner <span dir="ltr"><<a href="mailto:hans.huebner@gmail.com" target="_blank">hans.huebner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><div class="gmail_quote">2016-05-19 8:41 GMT+02:00 Robert Smith <span dir="ltr"><<a href="mailto:quad@symbo1ics.com" target="_blank">quad@symbo1ics.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>I am absolutely boggled by this attitude. This is an issue that one runs into when writing Common Lisp code, and not an issue that one runs into writing in another language and associated ecosystem. To me, that's a Lisp problem. We can do some creative academic definitions, I think, but it's a problem when choosing Lisp as a tool.</div><div></div></div></div></div></div></blockquote></div><br></div></span><div class="gmail_extra">The problem is not a Lisp problem.  It occurs in many language ecosystems, and it cannot generally be solved.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Things are relatively simple if you just look from the top to the bottom, from the usage of a lower-level library by a higher level library or application functionality.  Such usage could confined to within that tree of a linked application, e.g. by symbol or package renaming or the like, and similar techniques have been tried (in Lisp, but also in JVM languages and most likely elsewhere).</div><div class="gmail_extra"><br></div><div class="gmail_extra">The real issue though is data types defined by versioned libraries.  Suppose that an instance of a data type defined in library A version 1 is passed, through higher levels of the software, to version 2 of that same library.  How would one ever expect that to work?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Faré is completely right:  There is no way to apply some external magic to a hairball of different library versions of libraries and expect the result to work.  The only way to deal with it is to actually address the conflicting versions and make sure that all libraries in a system are prepared to use the same overall set of dependencies.  If a tool can help with detecting conflicts, it is great, and maybe that is what would be a good goal in the CL world to create such a tool and version tagging infrastructure.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I can report that in the Clojure world, every conference that I visited has at least a lightening talk on the subject of library versions and how to deal with them.  I have yet to see one where the presenter claims to have a solution, and most of these talks end up concluding that there is a possible problem which cannot generally be solved, but that many Clojure shops get away ignoring the problem.  We have been using the leiningen build tool to help us finding library version conflicts and generally strive towards smaller systems to reduce the number of dependencies that we need to synchronize, version-wise.</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">-Hans</div></font></span></div>
</blockquote></div><br></div>