LispWorks PE bundles an old asdf, which is loaded with (require "asdf").
CLISP optionally bundles asdf -- (require "asdf") -- and I would expect some Linux distributions to have that configuration in the CLISP they supply. (require "asdf") also looks in directories (including the user home directory!) for asdf.lisp, so an old version could be unintentionally loaded. My real concern is LispWorks, though.
Maybe this wasn't clear enough, but my communications here are on behalf of users, not me. Many -- perhaps most, perhaps nearly all -- people use asdf only indirectly through Quicklisp. I am trying to help the poor end-user who has a borked system and doesn't understand what is wrong. I would like to prevent the borkedness from happening in the first place.
Most people initialize Quicklisp in their startup file. After using the lisp image for a while, they may wish to load a system and discover that the system requires asdf3. So they load asdf3. And then everything is borked. It may be difficult even for an experienced user to discover what is wrong, much less a casual user, and next to impossible for a newcomer.
In the manual I didn't see any of the caveats you mention about the central registry. It says that asdf can be upgraded on the fly, and that's what people will expect. They don't expect that upgrading will bork the lisp image for some reason unknown to them.
The quick and dirty workaround I mentioned is not something that would be part of any real code, just something a user could do to get things unborked again, that is, to enable Quicklisp to load again.
I don't want to use *central-registry*. I'm not advocating using *central-registry*. I don't use *centry-registry* myself, except indirectly through Quicklisp. I am not insisting on weird upgrades. All I want to do is fix problems that end-users encounter.
On Wed, May 3, 2017 at 11:16 PM, Faré fahree@gmail.com wrote:
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