<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 19 Jan 2021, at 9:05, Wilfredo Velazquez wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Can I upgrade ASDF by simply placing the built asdf.lisp file in<br>
~/common-lisp/asdf/asdf.lisp and omitting everything else? Will ASDF find<br>
it?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I don't <em>believe</em> so -- the ASDF search mechanisms are all aimed at finding files with the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">.asd</code> extension. I'd have to look at the code (I'm not able to do this right now), but there would have to be a special case for files named "asdf.lisp". But I could be wrong.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">On Tue, Jan 19, 2021 at 9:44 AM Robert Goldman <rpgoldman@sift.info> wrote:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">*Warning -- opinionated rant follows!*<br>
<br>
On 18 Jan 2021, at 20:50, Eric Timmons wrote:<br>
<br>
That's not quite right. It could definitely be more friendly, but there<br>
are a few ways to better control it.<br>
<br>
To completely prevent ~/common-lisp/ from being traversed you could put<br>
an :ignore-inherited-configuration directive somewhere in the<br>
CL_SOURCE_REGISTRY envvar or<br>
$XDG_CONFIG_DIRS/common-lisp/source-registry.conf. But that approach<br>
also would prevent the files in<br>
$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d from being parsed<br>
(as well as any system level config). It might be nice to allow an<br>
inheritance config directive to be specified in the configuration<br>
directory parsing if it isn't already (there's an implicit<br>
:inherit-configuration tacked on the end of the directory based config).<br>
<br>
Another option is to drop a .cl-source-registry.cache file in<br>
~/common-lisp/ or one of the sub directories.<br>
<a href="https://common-lisp.net/project/asdf/asdf.html#Caching-Results" style="color:#999">https://common-lisp.net/project/asdf/asdf.html#Caching-Results</a>. ASDF<br>
will stop recursing if it finds that file and just use the info it<br>
contains.<br>
<br>
This is true, but it causes just the kind of problems I have alluded to --<br>
your ASDF configuration is now smeared all over your system, and debugging<br>
it becomes essentially impossible.<br>
<br>
I have repeatedly had to help people where I work who have put one of<br>
these magical -- and invisible -- files or configurations somewhere,<br>
forgotten it, and then don't understand why some aspect of their<br>
configuration is misbehaving. Now I tell people *only* to configure<br>
things in their lisp init files, *not* to use magical directories, and<br>
*not* to use environment variables. Then if something goes wrong, you<br>
know where to look for the culprit.<br>
<br>
Note also that if ASDF isn't configured in your lisp init file, but by a<br>
config file or environment variable, *it will be configured as it loads*.<br>
This means that all of your debugging tools are taken away from you. There<br>
will be no tracing, because by the time you can set up a trace, the damage<br>
will be done.<br>
<br>
asdf:*central-registry* is terribly inefficient, *but it is simple* and *it<br>
can be inspected when things go wrong*. None of these other schemes share<br>
that feature. I have tried to trace the control flow for interpreting the<br>
configuration DSL and it's a mass of twisty passages all exactly alike.<br>
Lots of key functionality is in variables, or in anonymous lambdas, making<br>
tracing effectively impossible. (Adding configuration logging would be a<br>
big help)<br>
<br>
So -- if you are at Google or some other shop where you have a zillion<br>
systems coming together, yes, *central-registry* is too slow, and will<br>
kill you. For most of us, though, using one of the alternatives is<br>
premature optimization.<br>
<br>
I am a strong believer that the only way to keep track of the burgeoning<br>
complexity of today's systems is to *localize* and *simplify*<br>
configuration, rather than disperse it. For some reason, the dispersion<br>
faction is winning the design game, though. I'm not sure why -- perhaps<br>
there's some notion of tidiness and elegance that encourages all of these<br>
configuration layering (look how elegant! You can override things or accept<br>
the default!) and dispersion (there's an individual config file for every<br>
purpose, instead of one monster -- and I admit my .emacs is a thing to<br>
strike fear in the heart).<br>
<br>
Also not a fan of invisible config files. Yeah -- it's ok to have dot<br>
files in your home dir so that you don't get overwhelmed, but why is it a<br>
good idea to hide the file in your repo that configures the CI so that ls<br>
won't show it to you?<br>
<br>
Finally, *everything* will break, so make sure you know how the poor user<br>
will debug it when it does. Make sure things are traceable in CL. Log<br>
things. Make your error messages understandable. Lots of ASDF doesn't<br>
follow this principle, and I would love to move towards making it easier to<br>
diagnose and debug.<br>
</p>
</blockquote><p dir="auto">-- <br>
Wilfredo Velázquez-Rodríguez</p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>