Anyone interested in "package versioning"?

[Alessio Stalla]

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.
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 (
https://commons.apache.org/proper/commons-lang/). 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 *can *provide their alternative package names, even if it's
not always the most sensible thing to do.
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.

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 *is *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).

Yes, that sucks. But not *that* 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 ;)


On 19 May 2016 at 09:58, Hans Hübner <hans.huebner at gmail.com> wrote:

> 2016-05-19 8:41 GMT+02:00 Robert Smith <quad at symbo1ics.com>:
>
>> 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.
>>
>
> The problem is not a Lisp problem.  It occurs in many language ecosystems,
> and it cannot generally be solved.
>
> 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).
>
> 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?
>
> 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.
>
> 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.
>
> -Hans
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20160519/38354e4f/attachment.html>