<p dir="ltr">The main thing is: do NOT use ASDF 2.<br>
Please address your complaints to Xach for the disservice of providing it.<br>
</p>
<br><div class="gmail_quote"><div dir="ltr">On Thu, May 4, 2017, 13:01 James M. Lawrence <<a href="mailto:llmjjmll@gmail.com">llmjjmll@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK I now see the last bullet point in "Pitfalls...", thanks. I had<br>
searched the manual for "central-registry", which isn't mentioned<br>
there directly.<br>
<br>
This part could be improved: "startup scripts should load, configure<br>
and upgrade ASDF among the very first things they do". Let's not tempt<br>
the user to configure before upgrading!<br>
<br>
Another bullet says, "Now that all implementations provide ASDF 3.1 or<br>
later...", but that's not true. LispWorks PE does not. Yes, it's LW<br>
version 6.1.1. And CLISP does not, though I understand that situation<br>
is somewhat forlorn.<br>
<br>
Here's the reason all this is immensely unexpected. If upgrading on<br>
the fly requires reconfiguration, then I wonder what the purpose of<br>
upgrading on the fly is supposed to be. Now that I understand that<br>
caveat, I don't know why the on-the-fly feature exists. If one already<br>
has such control over the configuration, then one wouldn't have loaded<br>
ASDF2 in the first place The whole purpose of on-the-fly upgrades, it<br>
seemed to me, was to handle the case where such control has passed.<br>
For example the situation I mentioned: the user has the bog standard<br>
Quicklisp setup in their init file and, after running an image for<br>
some time, needs to load an ASDF3-only library.<br>
<br>
I suppose the root problem here is LispWorks PE. Perhaps it should be<br>
put into the same category as CLISP. On the other hand I place high<br>
value on having things just work, no matter where the user is coming<br>
from. If that's not possible or too difficult or too annoying then so<br>
be it. It seemed reasonable to try.<br>
<br>
Best,<br>
lmj<br>
<br>
<br>
On Thu, May 4, 2017 at 11:30 AM, Robert Goldman <<a href="mailto:rpgoldman@sift.net" target="_blank">rpgoldman@sift.net</a>> wrote:<br>
> Actually, I find that there already WAS a discussion of just this issue<br>
> in the ASDF manual.  See the node "Pitfalls of the upgrade to ASDF 3."<br>
> I have added another FAQ node to try to make this information easier to<br>
> find, based on what went wrong.  Review welcome.<br>
><br>
> Cheers,<br>
> r<br>
><br>
><br>
> On 5/4/17 May 4 -9:59 AM, Robert Goldman wrote:<br>
>> On 5/4/17 May 4 -8:54 AM, James M. Lawrence wrote:<br>
>>> LispWorks PE bundles an old asdf, which is loaded with (require "asdf").<br>
>><br>
>> Is this because LWPE is still LW 6 instead of 7?<br>
>>><br>
>>> CLISP optionally bundles asdf -- (require "asdf") -- and I would<br>
>>> expect some Linux distributions to have that configuration in the<br>
>>> CLISP they supply. (require "asdf") also looks in directories<br>
>>> (including the user home directory!) for asdf.lisp, so an old version<br>
>>> could be unintentionally loaded. My real concern is LispWorks, though.<br>
>><br>
>> We can't really handle clisp effectively, because as far as releases are<br>
>> concerned, it's dead.  I realize that the code repo is active, but<br>
>> releases aren't being made, which means the de facto standard is now<br>
>> something going on 7 years old.  That's not the ASDF project's fault.<br>
>>><br>
>>> Maybe this wasn't clear enough, but my communications here are on<br>
>>> behalf of users, not me. Many -- perhaps most, perhaps nearly all --<br>
>>> people use asdf only indirectly through Quicklisp. I am trying to help<br>
>>> the poor end-user who has a borked system and doesn't understand what<br>
>>> is wrong. I would like to prevent the borkedness from happening in the<br>
>>> first place.<br>
>>><br>
>>> Most people initialize Quicklisp in their startup file. After using<br>
>>> the lisp image for a while, they may wish to load a system and<br>
>>> discover that the system requires asdf3. So they load asdf3. And then<br>
>>> everything is borked. It may be difficult even for an experienced user<br>
>>> to discover what is wrong, much less a casual user, and next to<br>
>>> impossible for a newcomer.<br>
>>><br>
>>> In the manual I didn't see any of the caveats you mention about the<br>
>>> central registry. It says that asdf can be upgraded on the fly, and<br>
>>> that's what people will expect. They don't expect that upgrading will<br>
>>> bork the lisp image for some reason unknown to them.<br>
>><br>
>> I will see if I can put in a FAQ about this.  Look for something soon.<br>
>>><br>
>>> The quick and dirty workaround I mentioned is not something that would<br>
>>> be part of any real code, just something a user could do to get things<br>
>>> unborked again, that is, to enable Quicklisp to load again.<br>
>>><br>
>>> I don't want to use *central-registry*. I'm not advocating using<br>
>>> *central-registry*. I don't use *centry-registry* myself, except<br>
>>> indirectly through Quicklisp. I am not insisting on weird upgrades.<br>
>>> All I want to do is fix problems that end-users encounter.<br>
>><br>
>> I'm not familiar with the guts of QL, but I thought QL didn't use<br>
>> central registry.  I thought it used its own extension to the loading<br>
>> process.<br>
>><br>
>> Best,<br>
>> R<br>
>><br>
>>><br>
>>><br>
>>> On Wed, May 3, 2017 at 11:16 PM, Faré <<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>> wrote:<br>
>>>> On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence <<a href="mailto:llmjjmll@gmail.com" target="_blank">llmjjmll@gmail.com</a>> wrote:<br>
>>>>> The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or<br>
>>>>> ASDF 3 on the fly", and "asdf:*central-registry* is not recommended<br>
>>>>> anymore, though we will continue to support it". >From the<br>
>>>>> documentation it is not immediately clear that upgrading is<br>
>>>>> purposefully broken.<br>
>>>>><br>
>>>> Upgrading works. Central-registry works. Central-registry is not<br>
>>>> preserved by upgrading. And doesn't need to be, because<br>
>>>> central-registry is something you insert into a special configuration<br>
>>>> file that needs to first load the proper asdf, anyway. Whoever writes<br>
>>>> that configuration file by hypothesis knows where all the software is<br>
>>>> located. It just doesn't make sense to load the wrong asdf then<br>
>>>> configure your central-registry only then to load yet another asdf. If<br>
>>>> you do things like that you deserve to lose.<br>
>>>><br>
>>>>> I suppose a quick and dirty workaround would be<br>
>>>>> something like (setf asdf:*central-registry*<br>
>>>>> asdf-2.26:*central-registry*).<br>
>>>> That doesn't make sense, and asdf cannot guess what ancient version of<br>
>>>> asdf was moved aside. Once again, it used to try much harder to<br>
>>>> upgrade from 2.26 on sbcl and several other implementations, but that<br>
>>>> got too unwieldy to support, for no good reason.<br>
>>>><br>
>>>><br>
>>>>> Quicklisp's behavior of using the asdf version bundled with the<br>
>>>>> implementation, if it exists, seems reasonable, at least at face<br>
>>>>> value. After all, that's the version the vendors tested, and it may<br>
>>>>> already be part of the image (or speedily loadable).<br>
>>>> That part is totally reasonable indeed, and works perfectly.<br>
>>>><br>
>>>>> Even if Quicklisp<br>
>>>>> includes asdf-3.1.7, it would still try to load the bundled version<br>
>>>>> first, so things would still be broken on LispWorks PE and CLISP.<br>
>>>>><br>
>>>> Does not compute. Neither LispWorks PE nor CLISP release from 2010<br>
>>>> provides ASDF. Quicklisp will then load its own ASDF, but that entails<br>
>>>> no upgrade. If you want a more recent ASDF on top of that provided by<br>
>>>> Quicklisp, you are going to lose anyway — instead overwrite<br>
>>>> Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade<br>
>>>> Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make<br>
>>>> your implementation provide ASDF despite it not being provided out of<br>
>>>> the box.<br>
>>>><br>
>>>> If you insist on such a weird upgrade, many things may go wrong beside<br>
>>>> the *central-registry*. Yet even then you shouldn't be using the<br>
>>>> *central-registry* to begin with. Use the source-registry.<br>
>>>><br>
>>>><br>
>>>>> Therefore the real question is whether people should load the asdf<br>
>>>>> bundled with the implementation, either on their own or through<br>
>>>>> Quicklisp. If upgrading wasn't broken, things would just work and we<br>
>>>>> wouldn't have to debate that question.<br>
>>>>><br>
>>>> Upgrading is not broken. Your use pattern is broken. Don't initialize<br>
>>>> the central registry after you load the wrong asdf then load the<br>
>>>> correct one then expect things to work.<br>
>>>><br>
>>>>> How about preserving *central-registry* when upgrading? That seems<br>
>>>>> completely natural and expected to me, even apart from the fact that<br>
>>>>> it happens to solve the problem at hand.<br>
>>>>><br>
>>>> It's completely unnatural and backwards to load a wrong asdf,<br>
>>>> initialize it, then upgrade it. Please configure *after* you upgrade<br>
>>>> (and yes, *if* the configuration is for ASDF to find ASDF itself, you<br>
>>>> may have to configure that part twice; or just skip the part about<br>
>>>> loading the wrong asdf). And try using install-asdf.lisp where<br>
>>>> applicable.<br>
>>>><br>
>>>> Finally, please don't use the central-registry for cases like these.<br>
>>>> Use the source-registry.<br>
>>>><br>
>>>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
>>>> Only a fool tests the depth of the water with both feet. — African proverb<br>
>>><br>
>><br>
>><br>
><br>
><br>
<br>
</blockquote></div>