[asdf-devel] asdf loading the same system twice?

[Faré]

Dear Nikodemus,

> Using quicklisp-installed libraries -- (ql:quickload "linedit"):
> [...]
> 4. (asdf:load-system :linedit)
>
> Observe that Alexandria is compiled and loaded twice. Once as a
> dependency of CFFI-GROVEL, once as a dependency of Linedit.
>
TL;DR:
(1) *If* you're going to have an asdf.asd in your source-registry,
  make sure it's at least 2.0.18.14.
(2) Then, use (asdf:upgrade-asdf) *after* you load quicklisp,
  but *before* you (asdf:load-system "linedit").

(When quicklisp's asdf is upgraded to 2.018.14 or later,
step (2) will hopefully not be necessary anymore, at least in this case.)

Full version:

I cannot reproduce your issue when I (ql:use-only-quicklisp-systems).
However, I am did find and fix problems when I am upgrading
quicklisp's asdf to a local asdf checkout.

Issues when upgrading asdf:

1- asdf:*system-definition-search-functions* is a defparameter,
 because a defvar would not have been backwards-compatible, but
 which cancels the changes done by quicklisp. Fixed in 2.018.14,
 where I use a defvar followed by an ad-hoc fixup form.

2- upgrading asdf loses the methods on e.g. perform.
 This is alright when you upgrade asdf on its own, with e.g.
 (asdf:upgrade-asdf) or (asdf:load-system :asdf) at the REPL,
 because upgrade-asdf invalidates existing systems with clear-systems,
 which will cause these systems to be reloaded and their methods re-defined.
 However, when asdf is upgraded as part of a chain of find-system's
 and load-system's (which is the case when osicat uses load-system
 to load cffi-grovel), things break down badly, as the systems
 that caused asdf to be upgraded are invalidated, but not reloaded
 before they are next used. Oops. 2.018.14 tries to be better in this case,
 and has a more forward-compatible protocol for upgrading, by trying to
 reload the systems being currently defined (which are being remembered
 to fix the previous infinite recursion bug you found in asdf using quicklisp
 back in may and fixed in 2.015.2), so that this problem will disappear
 in the future, but this protocol isn't active yet when you're
 upgrading *to* 2.018.14 from an earlier asdf.
 Therefore, the only safe way from quicklisp's asdf 2.017 is to use
 (asdf:upgrade-asdf) *after* you load quicklisp and *before* you try to
 load linedit.

3- 2.017.12 introduced a backwards incompatibility by modifying the
 signature of do-dep and do-one-dep without shadowing (with unintern)
 the previous versions, which causes further damage that prevents from
 seeing the effects described in 2. I assume you were ugprading ASDF
 from quicklisp's 2.017 to a local checkout of 2.017.12 or earlier.
 If this was not the case, then you may or may not be experiencing
 a different problem, one that I cannot reproduce with my current setup.

My, hot upgrade of the software doing the upgrade itself is hard to get right.

If problem persists, please contact me again on this list.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
``why'' is always relative to a model of possible explanations. It is never
an "absolute" question. Which is precisely what makes it meaningful.