"Solved" (was: Re: [asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 3.0.2.25)

[Faré]

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org


On Tue, Oct 22, 2013 at 3:57 PM, Dave Cooper <david.cooper at genworks.com> wrote:
>> I suppose the solution is for search-for-system-definition to treat
>> sysdef-preloaded-system-search specially and put it at the end of the
>> search, just like it magically puts find-system-if-being-defined
>> first. For backward compatibility, we can either remove
>> sysdef-preloaded-system-search from the
>> *system-definition-search-functions*, or have it become a no-op, and
>> have its effect magically at the end of search-for-system-definition
>> under a different name.
>
> But isn't uiop a bit of a special case? As I understand it, according to
> normal use, you would indeed want preloaded-systems to come first in the
> search, wouldn't you? Let's say I ship an image with cl-who built into it.
> Then the downstream user loads quicklisp and asdf (which I specifically do
> _not_ build into my image, but the current-version source code for which I
> provide with my distribution, with a convenient function for the user to
> load them).
>
> I plan to arrange for all the built-in systems to get registered immediately
> after the user loads quicklisp and asdf (of course the user could circumvent
> that if she really wanted to, but by default I would think this should be
> the case).
>
> Then let's say the user next loads some library which :depends-on (:cl-who).
> Since cl-who is built into the image, we really don't want quicklisp going
> out and fetching it again, do we? Isn't that the whole point of registering
> preloaded sytems?
>
Preloaded systems should come LAST, not first. If the user took pains
to install some source code, he probably wants to use it.

If the user wants to black out some of the systems in quicklisp that
would otherwise install some source, he may have to take some extra
steps, but these won't be builtin to asdf. Quicklisp should offer a
way to unregister some packages, and/or sysdef-preloaded-system-search
or a variant thereof can be explicitly tucked in front of the
quicklisp search functions in *system-definition-search-functions*. In
any case, this should NOT be the default behavior of ASDF — but you're
welcome to have gendl modify this default, if that makes things more
stable for your users.

That the current ASDF 3.0.2 preempts quicklisp in finding preloaded
systems is a bug in ASDF and/or quicklisp. (It's arguably a bug in
quicklisp that it didn't work around that misdesign in ASDF, but there
was still at least a distasteful design in ASDF, and it's now fixed in
3.0.2.34.) That bug wasn't too bad in 3.0.2 where the only systems
registered as preloaded were asdf (that isn't in quicklisp as a
distributed system anyway) and asdf-driver (which legacy name is only
used by a few legacy libraries that will accept a newer backward
compatible uiop) . But the bug just got worse in 3.0.2.x where uiop
and asdf-defsystem are also preloaded; in the hopefully near future,
asdf-package-system will be preloaded, too, as will any future asdf
extensions that get moved into asdf itself (notionally, we could have
included asdf-bundle, though no one depended on it by name, it seems;
asdf-utils could also have been registered as preloaded, but all users
have moved on).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Guns & bullets don't kill people — blood loss and organ damage kills people.