Here is something that has worried me for some time about ASDF. What
happens with internal libraries and libraries that are used by multiple
systems?
An example is split-sequence, which is packaged up and distributed
inside (portable) ASDF-INSTALL. If you are building something else,
you might well end up with a separate copy of split-sequence, that is
more normally installed. If you have installed a copy of
split-sequence later than you installed asdf-install, and then do
(asdf:oos 'asdf:load-op :split-sequence), that new copy will be loaded,
crushing the one you earlier loaded with asdf-install.
This seems not so good, especially if the two copies of split-sequence
were to diverge.
In general, it seems that one might wish to permit loading multiple
different copies of a library, for different version numbers. But this
doesn't actually sit very happily with the package system.
Does anyone have a way around this problem?
"RPG" <·········@gmail.com> writes:
> Here is something that has worried me for some time about ASDF. What
> happens with internal libraries and libraries that are used by multiple
> systems?
>
> An example is split-sequence, which is packaged up and distributed
> inside (portable) ASDF-INSTALL. If you are building something else,
> you might well end up with a separate copy of split-sequence, that is
> more normally installed. If you have installed a copy of
> split-sequence later than you installed asdf-install, and then do
> (asdf:oos 'asdf:load-op :split-sequence), that new copy will be loaded,
> crushing the one you earlier loaded with asdf-install.
>
> This seems not so good, especially if the two copies of split-sequence
> were to diverge.
>
> In general, it seems that one might wish to permit loading multiple
> different copies of a library, for different version numbers. But this
> doesn't actually sit very happily with the package system.
>
> Does anyone have a way around this problem?
Of course. You need to impose some structure on the package names.
Let the system distribution system reject package unqualified system
and package names (such as SPLIT-SEQUENCE), and impose a format like:
rev.ersed.domain.name.system-name.version
rev.ersed.domain.name.package-name.version
For example, you would have:
In the system: COM.INFORMATIMAGO.COMMON-LISP.203
there are the packages:
COM.INFORMATIMAGO.COMMON-LISP.SPLIT-SEQUENCE.1
COM.INFORMATIMAGO.COMMON-LISP.UTILITY.200
COM.INFORMATIMAGO.COMMON-LISP.STRING.192
...
In the system: NET.TELENT.SPLIT-SEQUENCE.32
there are the packages: NET.TELENT.SPLIT-SEQUENCE.29
NET.TELENT.SPLIT-SEQUENCE-SYSTEM.31
(A system a.b.c can verywell include packages from another domain e.f.g
if the packager of the system is not the author of the packages.)
The package system needs some improvements.
See for example Franz's hierarchical packages.
Let's add handling of versions.
(use-package '(= "NET.TELENT.SPLIT-SEQUENCE.17"))
(use-package '(>= "NET.TELENT.SPLIT-SEQUENCE.32"))
Nicknames should have package scope, instead of global (colliding) scope.
(in-package :user-of-split-sequence)
(package-bind-nickname '(>= "NET.TELENT.SPLIT-SEQUENCE.17") "SPLIT")
(split:split-sequence ...) ; calls function from version 32 of the package
(in-package :other-user-of-split-sequence)
(package-bind-nickname '(< "NET.TELENT.SPLIT-SEQUENCE.10") "SPLIT")
(split:split-sequence ...) ; calls function from version 9 of the package
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
By and large I think that this is on the right track. I'd just like to
point out that the picture is complicated by the fact that we have two
different language constructs: packages and package names on the one
hand, and ASDF systems, on the other.
So your use-package solution elegantly solves one problem --- allowing
multiple copies of the same namespace to coexist --- but doesn't help
with the ASDF solution. Ideally, of course, the two would dovetail, so
that somehow one could, say, put versioning information in the ASDF
dependencies and automagically get the right package use relations.
[BTW, isn't :use-package really a sort of a short-form? I.e., isn't
the primary relationship the IMPORT relationship, which should be
changed, and then use-package is really just a wholesale import? Full
disclosure: I type this without having checked the ANSI spec...]
Best.
R