Upgrade failures for asdf-3.1.7 and later

[Faré]

On Thu, May 4, 2017 at 4:52 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> On 5/4/17 May 4 -2:34 PM, Faré wrote:
>> In any case, friends don't let novices use the central-registry.
>
> The counter-argument to this is that *central-registry* is much more
> conceptually simple and easier to debug than the new configuration
> framework.
>
The problem with central-registry is a bootstrap problem.
It requires everyone to be a system administrator and edit configuration files.

> If I write code that populates my *central-registry*, I can trace that
> code and I can look at the *central-registry*.  It's as easy as (PPRINT
> asdf:*central-registry*)
>
But to write that code, you must be an expert who can intercept CL
configuration and be productive in that bootstrap environment.

But then you can just as well call (asdf:initialize-source-registry)
and inspect the contents of asdf::*source-registry* or what is
returned by (asdf/source-registry:flatten-source-registry), or trace
functions in the source-registry. But mostly you don't need to,
because it just works out of the box without configuration.

> At least in the past, if you added a new asd file to a directory in the
> *central-registry*, then ASDF would find it.  If you add it to somewhere
> covered by the new configuration framework, it won't, will it? because
> the new configuration framework eagerly searches for asd files.
>
> (Admittedly, *central-registry* scales poorly for very large programs).
>
You may indeed need to re-run (asdf:initialize-source-registry) after
you install or remove .asd files. That is documented, and a small
price to pay for scaling the registry much beyond what the
*central-registry* will crumble with.

> For the new configuration arrangements, things are much more difficult
> for a novice to understand.  The actual configuration is held in tables
> that are opaque (yes, they can be dumped, but it's non-trivial and not
> discussed in the manual).
>
A novice does not need to understand it. If you follow the
instructions, such as "install your software under ~/common-lisp/",
then it Just Works™.

Experts can dump tables. I hesitated about replicating
alexandria:hash-table-alist in uiop, to make it easy to dump some
tables. Decided against it in the end, but if you believe novices
should be able to dump those tables, that's something to consider.

> Much of the configuration code cannot be traced because key operations
> take place in side-effecting anonymous lambdas.
>
That code is not the most readable, but what it does it well
documented, well debugged, and it's easy to look at the result, change
something and look at the result again.

> Finally, if you configure with configuration files in your XDG config
> directories, there's not even a chance to trace, because by the time you
> could set up a trace, the configuration's been loaded.
>
It doesn't actually make tracing harder than usual. Tracing asdf
configuration is a normally hard bootstrap issue.

> In short, while the new configuration structure is better in many ways,
> that's only if it works.  If something odd happens, it leaves you pretty
> flat.  If you have a small set of libraries in use, *central-registry*
> can be a lot easier to deal with.
>
On the other hand, the source-registry often "just works" out of the
box, or requires a one-liner to configure. The *central-registry* is
cognitively much heavier, especially so on novices.

> I've been meaning to provide more debugging to the configuration
> process, but just keeping up with everyone else's mods to ASDF has
> eaten all the ASDF time I have for now.
>
That would be a good thing.

When you have time, a post hoc review of the changes from 3.2.0 to
3.2.1 would be nice. Also a review of the plan branch, and some
opinions on what to do about syntax-control and when.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Conservative, n.:
        One who admires radicals centuries after they're dead.
                — Leo C. Rosten