On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence llmjjmll@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