Using different versions of systems on the same machine

[dfmor...@gmail.com]

I'm running multiple things on the same machine that have, or, rather, are about to have, different version dependencies: the current, working thingie depends upon older versions of several systems, and I'm about to work on upgrading things to use the newer versions, but need to do so in a clean fashion that doesn't disrupt the working one. As I understand it, if I do a ql:update-dist everything on the machine is going to see the new version, potentially making the working version my code no longer a working version.

Even worse, in the near future I expect to have two different working thingies that, at least for a time, may each depend upon different version of some systems.

What's the best way to deal with this in Quicklisp?

The scheme I'm thinking of adopting is keeping multiple, different Quicklisp universes. So, instead of having just ~/quicklisp/, I'll have ~/quicklisp-dev/, ~/quicklisp-app-1/, ~/quicklisp-app-2/, etc. Where each may potentially have different versions of various systems. Then launch Lisp without an init file and load the setup.lisp from the appropriate directory when I need to care about versions.

Anyway, is this the approriate way to deal with stuff, or is there A Better Way?

It seems the easiest way to create an alternate quicklisp is to just launch Lisp without an init file, load quicklisp.lisp, and then use the :path argument to quicklisp-quickstart:install. And use ql-dist:install-dist, followed by the appropriate ql:quickloads to get the systems from some appropriate point in the past. That locks you into only using versions that were all the officially latest at the same point in time, but that's probably a feature, since otherwise a version skew hell would be possible.

Again, is this the best way to deal with this?

[Zach Beane]

Yes, I think you've described the best way to do that with Quicklisp.

Zach

--
You received this message because you are subscribed to the Google Groups "Quicklisp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quicklisp+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastian Christ]

>>>>> "d" == dfmorrison-Re5JQEeQqe8AvxtiuMwx3w <dfmor...@gmail.com> writes:

d> I'm running multiple things on the same machine that have, or, rather, are
d> about to have, different version dependencies: the current, working thingie
d> depends upon older versions of several systems, and I'm about to work on
d> upgrading things to use the newer versions, but need to do so in a clean
d> fashion that doesn't disrupt the working one. As I understand it, if I do a
d> ql:update-dist everything on the machine is going to see the new version,
d> potentially making the working version my code no longer a working version.

d> Even worse, in the near future I expect to have two different working
d> thingies that, at least for a time, may each depend upon different version
d> of some systems.

d> What's the best way to deal with this in Quicklisp?

d> The scheme I'm thinking of adopting is keeping multiple, different
d> Quicklisp universes. So, instead of having just ~/quicklisp/, I'll have
d> ~/quicklisp-dev/, ~/quicklisp-app-1/, ~/quicklisp-app-2/, etc. Where each
d> may potentially have different versions of various systems. Then launch
d> Lisp without an init file and load the setup.lisp from the appropriate
d> directory when I need to care about versions.

d> Anyway, is this the approriate way to deal with stuff, or is there A Better
d> Way?

d> It seems the easiest way to create an alternate quicklisp is to just launch
d> Lisp without an init file, load quicklisp.lisp, and then use the :path
d> argument to quicklisp-quickstart:install. And use ql-dist:install-dist,
d> followed by the appropriate ql:quickloads to get the systems from some
d> appropriate point in the past. That locks you into only using versions that
d> were all the officially latest at the same point in time, but that's
d> probably a feature, since otherwise a version skew hell would be possible.

d> Again, is this the best way to deal with this?


There is also qlot: https://github.com/fukamachi/qlot

Regards,

Sebastian

--
Sebastian (Rudolfo) Christ
http://rudolfochrist.github.io
GPG Fingerprint: 306D 8FD3 DFB6 4E44 5061
CE71 6407 D6F8 2AC5 55DD