Upgrade failures for asdf-3.1.7 and later

[James M. Lawrence]

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 at 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 at 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
>