Upgrade failures for asdf-3.1.7 and later

[Robert Goldman]

On 5/3/17 May 3 -2:30 PM, Daniel Kochmański wrote:
> Is there any chance for specification of the "core ASDF protocol" -
> subset guaranteed to not change every few years, so one may write today
> systems which will be loadadable in the future?

This question really isn't germane to the original post.  The original
post was a question about online upgrade, which is simply impossible in
some cases.

If you would like to raise this issue again, I suggest doing it with a
subject line that more correctly fits the topic.

That said, the core ASDF protocol really hasn't changed much at all.
Most of the changes have been extensions.  The few exceptions lie with
deprecated lower-level interfaces.  A first step to stabilizing this
would be to document all of the interface functions, variables, and
classes.  But that's a lot of work.  The documentation is getting
better, but slowly.

Best,
r

> 
> Regards,
> Daniel
> 
> Faré writes:
> 
>> 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
> 
> 
> --
> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
> TurtleWare - Daniel Kochmański      | www.turtleware.eu
> 
> "Be the change that you wish to see in the world." - Mahatma Gandhi
>