Is it possible to load multiple versions of the same system?

[Ian Tegebo]

Thanks for the detailed response.  Comments inline,

On Fri, Apr 29, 2016 at 2:23 AM, Faré <fahree at gmail.com> wrote:

> On Thu, Apr 28, 2016 at 8:05 PM, Ian Tegebo <ian.tegebo at gmail.com> wrote:
> > I've been reading the manual, papers, and slides on ASDF and XCVB.  As a
> > frame of reference, I prefer the qualities exhibited by Racket's
> > implementation of modules.  I was disappointed both to see XCVB bitrot,
> and
> > then to see that a major ASDF overhaul would be necessary.
> >
> [...]
> As to me, if I had to design a build system today... see
> http://ngnghm.github.io/blog/2016/04/26/chapter-9-build-systems/
>

I've booked travel to the Land of the Houyhnhnms , but have yet to depart.

> That said, ignoring Racket/ASDF/XCVB, I'm curious about how loading
> multiple
> > versions of the same system could possibly be implemented in Common Lisp
> > (CL). [...]
> >
> What is your use case? Do you want a fully automated general answer,
> or just a manual hack that works for one or a few very specific
> systems on a specific implementation? In the former case, you're
> facing an uphill battle. In the latter case, many hacks can help you.
>

The former is intriguing, the latter's useful.  Curiosity about a general
solution is what prompted this thread, but I'm happy to learn of
workarounds.


> Various hacks:
>
> [...]
> * detecting packages present before and after loading the system
> itself, so you can rename them away.
> * using my system package-renaming to cleverly rename relevant
> packages around the compilation, loading and/or use of one system.
> * fixing your systems to not refer to packages by name at run-time,
> and if possible not at load-time either (or make sure to wrapper
> load-time in proper package-renaming).


With respect to package renaming, I've asked Michał Herda to comment on
whatever issues he'd had with "destructive package renaming" [1].  I
understand it as referring to the state-based global-reader implementation
of packages, which seems to entail well known problems like reentrancy and
readtable leakage.

Would you correct me or otherwise expand on the matter?  I.e. I'm trying to
understand the tradeoffs between package renaming methods.  My use cases
are:

a) package local nicknames for readability
b) implementing a variant of Racket's "#lang"
c) supporting multiple versions of a dependency

I know that some implementations directly  support a), and that both a) and
b) may be implemented with ASDF, but I didn't know about c).


> On the JVM, there's the notion of "classloader" that can be used to load
> > multiple versions of the same class.  Unfortunately, the only approach I
> can
> > imagine is to use some form of package renaming.
>
> If what you want is a general way to have multiple versions of any
> system in a same image, you're out of luck, and/or [...]
>

Yes, I'm primarily interested in a general way: thanks for entertaining the
discussion.

If what you want is a build system that is full-featured like XCVB
> with plenty of dependencies yet compiles things in-image like ASDF [...]

Or then again,
> you could use the XCVB farmer model, where the build image with lots
> of dependencies farms the compilation to workers that only need to
> load a small stub, and no package renaming is necessary.


This approach sounds like one motivated by version conflict between the
build system and system being built.  Is that correct?

I wasn't really thinking about that, but now that I am I'm reminded of
various parts of your paper [2].  The bootstrapping, upgrading, and
distribution of ASDF seems very thorny indeed.

[1]: https://github.com/phoe-krk/pseudonyms/issues/2#issuecomment-215534567
[2]: http://fare.tunes.org/files/asdf3/asdf3-2014.html

-- 
Ian Tegebo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20160429/476f7bfb/attachment-0001.html>