[asdf-devel] [RfC] default value for *central-registry*

Faré fahree at gmail.com
Thu Sep 24 11:24:26 UTC 2009

2009/9/24 Daniel Herring <dherring at tentpost.com>:
> Regarding Tobias's question, if CL/ASDF take off, I think people will want
> more than one default location.  On a unix machine, they might be /usr/asdf,
> /usr/local/asdf, and ~/.asdf.  On Windows, they might be C:\asdf,
> C:\Windows\asdf, and $HOME\asdf (I forget the exact $HOME variable name
> right now).
What about making it not specific to asdf but general to common-lisp,
including any future replacement for asdf, be it xcvb, mudballs or

And so the things to push in the *central-registry* would be
/usr/share/common-lisp/systems/   (currently used by debian)
/usr/local/share/common-lisp/systems/  (for non-distribution-managed
system-installed systems?)
~/.common-lisp/systems/ or maybe ~/.local/share/common-lisp/systems/
(for user-installed systems?)

Now, now, now. What about instead exporting COMMON_LISP_PATH to default to
or whatever, and have ASDF either recurse through these directories or
go to the systems directory underneath? This would allow sharing the
configuration variable with XCVB and future CL software management
systems, unlike an ASDF-specific ASDF_PATH.

> As Faré pointed out, these should be specified through a site-specific
> configuration rather than being hard-coded into ASDF.  Such configuration
> might involve querying an environment variable or reading a config file from
> a known location (that's how most shells set these environment variables).
> If reading config files, the two major conventions I know are
> - read the global config, then the user config, possibly overwriting
> settings
> - read the first available config file, trying the user config then the
> global config
Similarly, if we are to have configuration files, what about the following?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
...so that IBM Java envangelist tells me "nothing spread as fast as Java",
to which I answer: "crack!"...

More information about the asdf-devel mailing list