[asdf-devel] summary proposal for COMMON_LISP_PATH and system search changes

[Daniel Herring]

On Sun, 27 Sep 2009, Gary King wrote:

> Here is a summary of what I've heard and what I think we should do.

Looks like a good direction.  These changes may justify bumping the ASDF 
version number to 2.0.  My comments follow.


> ##  default value for *central-registry*
>
> COMMON_LISP_PATH environment variable with syntax like
>     path[;path]*

How about CL_PATH or CL_SYSTEM_PATH?

As others noted, the value should have an OS-dependent syntax.
POSIX:     path[:path]*
Microsoft: path[;path]*
Both syntaxes should ignore an empty path (e.g. "path1:path2:") and 
should not require paths to have a trailing slash (a common source 
of errors).


> This is used by ASDF to help build the default value for
> `*central-registry*`.
>
> If not specified, `*central-registry*` defaults to (on
> *nix-like systems):
...
These look fine.

> (The last two would need to be different for Windows-based
> systems.)

Something like c:\common-lisp and c:\windows\common-lisp ?

It would be nice if the defaults could be invoked by shell users.  Then 
they could write CL_SYSTEM_PATH=DEFAULT_CL_SYSTEM_PATH:/opt/common-lisp.


> ## modification for `sysdef-central-registry-search`
>
> Currently `sysdef-central-registry-search` searches in the
> top-level of each directory in `*central-registry*` to find
> systems. If we use the above, then a more useful approach
> would be to search in the top-level and in a sub-directory
> named `systems`. An even more useful approach would to search
> in all sub-directories of each entry.

Searching an extra "systems" subdirectory seems redundant; to follow 
common-lisp-controller, make it an explicit part of 
DEFAULT_CL_SYSTEM_PATH.  Searching subdirectories for arbitrary *.asd 
files seems too loose.  If ASDF chooses to search subdirectories, it might 
be good to follow the pattern set by make, Java, and Apple; search for a 
single file in each subdirectory (e.g. the makefile, the jar manifest, the 
.app Info.plist, an ASDF system.asd).

I like James's idea.  Let CL_SYSTEM_PATH=path1:path2.  Then (asdf:oos 
'asdf:load-op :babel) will use the first of path1/babel/system.asd and 
path2/babel/system.asd.  Nothing else to search.  No loading asd files 
until the proper one is found.  For backwards compatibility, ASDF can 
continue looking for $PATH/*.asd without checking subdirectories.


> ## configuration file
>
> When ASDF starts, it will:
>
>  1. setup `*central-registry*` using its own defaults and the
> `COMMON_LISP_PATH` environment variable.
>
>  2. look for (and load if it is found) a file named
> `asdf-config.lisp` in each of these paths traversed in
> _reverse_ order (so that user settings take precedence overs
> system ones). Note that the ASDF package will exist when this
> file is read.
>
> I.e., I'm suggesting that we go the "user settings overwrite
> system settings" route rather than the "if there are any user
> settings, then ignore the system settings" one.

That works, but I think shells use the first available for a reason:  it 
is easier to explicitly include a system file than it is to undo unwanted 
changes.  Also, such config files generally don't belong in PATH; how 
about ~/.asdf.lisp and /etc/asdf.lisp.

This file will be used to configure stuff like asdf-binary-locations, 
correct?  IMO, the config file should be loaded before the CL_SYSTEM_PATH 
variable is used.  They could usefully modify DEFAULT_CL_SYSTEM_PATH; but 
they should never modify the actual CL_SYSTEM_PATH (e.g. a shell script 
may need custom settings).


Later,
Daniel