The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken. I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable). Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
On Wed, May 3, 2017 at 3:19 PM, Faré fahree@gmail.com wrote:
This is totally intentional and well-documented.
Do NOT use the central-registry if you don't know what you're doing. Use the source-registry as recommended. (Or, if you truly insist, reinitialize the central-registry after upgrade; upgrading from ASDF 2 will create a fresh ASDF package; see asdf/tools/load-asdf.lisp for how to load ASDF while supporting backward compatibility back to ASDF 1 the hard way).
Do NOT use ASDF 2.26 (from October 2012), ever. Help me convince Xach to stop distributing that bitrotting piece of maintenance nightmare. Seriously, it's a shame that Quicklisp isn't distributing ASDF 3.1.7 (from May 2016), which is the very stable culmination of the 3.1 series and works great with all its systems. And I totally understand that Quicklisp must be conservative and should not upgrade to the latest 3.2.1 (from April 2017) yet. Considering how badly ASDF 2.26 now behaves when trying to load systems from Quicklisp, I wonder if Xach even ever tests it; I bet not. Alternatively, to show how utterly ridiculous his attitude is, convince him to distribute ASDF 1.85 (from May 2004) instead, the perfect gem that Dan Barlow bequeathed us (). Or no more recent 1.366 (from September 2009), the last version wholly untainted by my code contributions.
-#f
On May 3, 2017 2:23 PM, "James M. Lawrence" llmjjmll@gmail.com wrote:
Starting with a bare lisp image (e.g --no-userinit --no-sysinit for SBCL), the following signals a "component not found" error:
(load "asdf-2.26.lisp") ;;; or whatever system you want (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/" asdf:*central-registry*) (load "asdf-3.2.1.lisp") (asdf:load-system "alexandria")
The first bad commit is https://github.com/fare/asdf/commit/3a9457a
I hope this wasn't intentional? Ideally an old asdf version would never get loaded, but practically speaking it sometimes does (e.g. on LispWorks PE and CLISP). And if that happens, thereafter one is unable to load a system that requires asdf-3. The above case is a whittled-down version of a quickloading problem.
Best, lmj