Upgrading/Installation Instructions Clarification

[Robert Goldman]

**Warning -- opinionated rant follows!**

On 18 Jan 2021, at 20:50, Eric Timmons wrote:

> That's not quite right. It could definitely be more friendly, but 
> there
> are a few ways to better control it.
>
> To completely prevent ~/common-lisp/ from being traversed you could 
> put
> an :ignore-inherited-configuration directive somewhere in the
> CL_SOURCE_REGISTRY envvar or
> $XDG_CONFIG_DIRS/common-lisp/source-registry.conf. But that approach
> also would prevent the files in
> $XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d from being parsed
> (as well as any system level config). It might be nice to allow an
> inheritance config directive to be specified in the configuration
> directory parsing if it isn't already (there's an implicit
> :inherit-configuration tacked on the end of the directory based 
> config).
>
> Another option is to drop a .cl-source-registry.cache file in
> ~/common-lisp/ or one of the sub directories.
> <https://common-lisp.net/project/asdf/asdf.html#Caching-Results>. ASDF
> will stop recursing if it finds that file and just use the info it
> contains.

This is true, but it causes just the kind of problems I have alluded to 
-- your ASDF configuration is now smeared all over your system, and 
debugging it becomes essentially impossible.

I have repeatedly had to help people where I work who have put one of 
these magical -- and invisible -- files or configurations somewhere, 
forgotten it, and then don't understand why some aspect of their 
configuration is misbehaving.  Now I tell people *only* to configure 
things in their lisp init files, *not* to use magical directories, and 
*not* to use environment variables.  Then if something goes wrong, you 
know where to look for the culprit.

Note also that if ASDF isn't configured in your lisp init file, but by a 
config file or environment variable, *it will be configured as it 
loads*.  This means that all of your debugging tools are taken away from 
you.  There will be no tracing, because by the time you can set up a 
trace, the damage will be done.

`asdf:*central-registry*` is terribly inefficient, *but it is simple* 
and *it can be inspected when things go wrong*.  None of these other 
schemes share that feature.  I have tried to trace the control flow for 
interpreting the configuration DSL and it's a mass of twisty passages 
all exactly alike.  Lots of key functionality is in variables, or in 
anonymous lambdas, making tracing effectively impossible.  (Adding 
configuration logging would be a big help)

So -- if you are at Google or some other shop where you have a zillion 
systems coming together, yes, `*central-registry*` is too slow, and will 
kill you.  For most of us, though, using one of the alternatives is 
premature optimization.

I am a strong believer that the only way to keep track of the burgeoning 
complexity of today's systems is to *localize* and *simplify* 
configuration, rather than disperse it.  For some reason, the dispersion 
faction is winning the design game, though.  I'm not sure why -- perhaps 
there's some notion of tidiness and elegance that encourages all of 
these configuration layering (look how elegant! You can override things 
or accept the default!) and dispersion (there's an individual config 
file for every purpose, instead of one monster -- and I admit my 
`.emacs` is a thing to strike fear in the heart).

Also not a fan of invisible config files.  Yeah -- it's ok to have dot 
files in your home dir so that you don't get overwhelmed, but why is it 
a good idea to hide the file in your repo that configures the CI so that 
`ls` won't show it to you?

Finally, *everything* will break, so make sure you know how the poor 
user will debug it when it does.  Make sure things are traceable in CL. 
Log things.  Make your error messages understandable.  Lots of ASDF 
doesn't follow this principle, and I would love to move towards making 
it easier to diagnose and debug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20210119/e6235ebe/attachment.html>