Upgrade failures for asdf-3.1.7 and later

[Robert Goldman]

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.

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*)

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).

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).

Much of the configuration code cannot be traced because key operations
take place in side-effecting anonymous lambdas.

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.

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.

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.