Re: ASDF, Windows, symlinks

Daniel Barlow <[email protected]> writes:
> Kevin Layer wrote:
>> I'll end with a question.  Since something drove the authors of ASDF
>> to make the design choice they did, can someone shed some light on
>> what it was?  As is often the case with bad design choices, there is
>> sometimes a better solution.  Perhaps the original problem can be
>> framed here so that we can all help think of a better solution than
>> what we have.
>
> OK, it reflects concerns of free software authors ;-)  More 
> grandiloquently, it's designed to ease development in the kind of 
> distributed software ecosystem where any module might depend on multiple 
> other modules developed by other people, it is common to want to use 
> someone else's development code (by tracking their version control 
> repository), and "finished" is considered a synonym for "dead"
>
> It's simply one possible implementation of a mapping from system name to 
> the place on disk where that system may be found.  The primary concern 
> is that the author of system A (by definition the "owner" of A.asd) 
> will not in general know where the user of his system has installed the 
> systems L and M on which it depends.

I think that following the .asd's symlink to the original file should
rightly be considered as part of finding the system in the first
place.  I.e., such logic belongs in sysdef-central-registry-search, if
anywhere.  This also makes it easily customizable.  These points were
already made by Richard Kreuter in another message, but I think bear
repeating.  (Making that change would break compatibility, as he noted.)

> * Having the the user specify some directory or some few directories 
> which are recursively searched for modules is also suboptimal: he may 
> have multiple versions of L and M - perhaps, a released version and a 
> development version, or a pristine HEAD and a scratch area with local 
> changes.  He will probably want to specify explicitly - and will 
> certainly want to know definitely - which is in use.  This tends to 
> militate against any magic "use the first we find" answer, which might 
> be upset by an OS upgrade, or the installation of some other software: 
> far better a solution in which an explicit step is needed to switch from 
> one source of L to another.

I don't see that these are necessarily in conflict.  Current practice
is to specify some directory, and then explicitly symlink .asd files
into it.  How is that appreciably different from specifying some
directory, and then explicitly symlinking whole source directories
into it?  I.e., instead of having ~/.sbcl/systems contain

ironclad.asd -> /usr/src/ironclad_0.22/ironclad.asd

it could contain a symlink to the directory:

ironclad -> /usr/src/ironclad_0.22

And then the sysdef search could look for <registry>/name/name.asd

That seems to give you the same level of explicit control, but asdf
wouldn't need to care the least bit about the symlinks.


Todd

p.s., Assuming that asdf's defaults are unlikely to change
incompatibly, and that Franz apparently have a policy forbidding
site-init files, it seems the easiest way for them to get what they
want might be to modify their .asd files to include ":pathname
*load-pathname*".  This is contrary to the spirit of asdf, but given
their requirements, maybe it'd be best for them?

-- 
Todd Sabin                                          <[email protected]>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/