Anyone interested in "package versioning"?

Hans Hübner hans.huebner at gmail.com
Thu May 19 07:58:25 UTC 2016


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/8bec1bc8/attachment-0001.html>


More information about the pro mailing list