Upgrade failures for asdf-3.1.7 and later

[Faré]

On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence <llmjjmll at gmail.com> wrote:
> 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.
>
Upgrading works. Central-registry works. Central-registry is not
preserved by upgrading. And doesn't need to be, because
central-registry is something you insert into a special configuration
file that needs to first load the proper asdf, anyway. Whoever writes
that configuration file by hypothesis knows where all the software is
located. It just doesn't make sense to load the wrong asdf then
configure your central-registry only then to load yet another asdf. If
you do things like that you deserve to lose.

> I suppose a quick and dirty workaround would be
> something like (setf asdf:*central-registry*
> asdf-2.26:*central-registry*).
That doesn't make sense, and asdf cannot guess what ancient version of
asdf was moved aside. Once again, it used to try much harder to
upgrade from 2.26 on sbcl and several other implementations, but that
got too unwieldy to support, for no good reason.


> 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).
That part is totally reasonable indeed, and works perfectly.

> 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.
>
Does not compute. Neither LispWorks PE nor CLISP release from 2010
provides ASDF. Quicklisp will then load its own ASDF, but that entails
no upgrade. If you want a more recent ASDF on top of that provided by
Quicklisp, you are going to lose anyway — instead overwrite
Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade
Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make
your implementation provide ASDF despite it not being provided out of
the box.

If you insist on such a weird upgrade, many things may go wrong beside
the *central-registry*. Yet even then you shouldn't be using the
*central-registry* to begin with. Use the source-registry.


> 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.
>
Upgrading is not broken. Your use pattern is broken. Don't initialize
the central registry after you load the wrong asdf then load the
correct one then expect things to work.

> 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.
>
It's completely unnatural and backwards to load a wrong asdf,
initialize it, then upgrade it. Please configure *after* you upgrade
(and yes, *if* the configuration is for ASDF to find ASDF itself, you
may have to configure that part twice; or just skip the part about
loading the wrong asdf). And try using install-asdf.lisp where
applicable.

Finally, please don't use the central-registry for cases like these.
Use the source-registry.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Only a fool tests the depth of the water with both feet. — African proverb