Anyone interested in "package versioning"?

[Robert Smith]

On Wed, May 18, 2016 at 4:57 AM, Alessio Stalla <alessiostalla at gmail.com>
wrote:

> The stance on packages found in the mentioned Quora post is based on the
> old misconception about packages being modules, or "software packages" in
> the Linux distribution sense. They're not. They are really just namespaces,
> containers of symbols. So it does not make any sense, to me, that they have
> versions. Software has versions, not names.


I thought I might as well clarify what I meant, since I wrote it.

Systems are what should get versioned but systems are not what are referred
to by source files. Systems largely coordinate the compilation and loading
of files. Source files generally have no notion of a system, actually,
which may be what is ultimately problematic. Packages are referred to by
source files, however. When I said packages, I meant it, and it was not a
conflation with the notion of a system.

At the companies I have worked in, we rake in 100s of systems, which
consist of n*100s of systems where n is the average number of packages per
system. These version collisions happen enough, and we are lucky when
they're not silent. Often enough, it's an extremely subtle issue that
system A depends on {system B at time T1} and system C depends on {system B
at time T2}, where T1 and T2 correspond to different versions of system B,
even if not explicitly labeled as such.

Let's suppose we simplify the problem however and assume that B has been
properly versioned in time, and systems A and C refer properly to the
correct version of system B as a dependency. Even then, they will not be
able to be simultaneously loaded in a functionally correct fashion. (They
*can* both be loaded, but you'll do some clobbering of state along the way.)

Whether we think about modules as systems or as packages or as whatever,
the problem would need to be addressed at the package level, if we are not
assuming that we can't synchronize the universe of people writing Common
Lisp.

Overall, I'd summarize as this. Whether we have the technology in the
Common Lisp ecosystem to accommodate this problem or not, it's my opinion
and the opinion of many of my colleagues that there is a problem for
development teams making extensive use of open and closed source code.
There definitely is not a discipline that you see with other languages and
their ecosystems (JS/npm, Clojure, etc.) about proper versioning of systems
and furthermore proper loading of the proper versions. I don't think that's
debatable. The closest we have to this solution is relying on the global
nature of a particular Quicklisp distribution, but not all Lisp software is
free and open source, and even software within Quicklisp has tons of
implied version dependencies.

Regards,

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20160518/e4d4c206/attachment-0001.html>