[asdf-devel] ASDF:OOS LOAD-OP :FORCE T and SBCL contribs

[Robert Goldman]

Nikodemus Siivola wrote:
> 2009/5/13 Robert Goldman <rpgoldman at sift.info>:
> 
> I remain confused on "what installer" -- but nevermind.
> 
>> I was also thinking "eugh" in response to that alternative.  So I
> 
> Just the be clear, the "eugh" did not apply to the first option, which
> seems the most natural one to me.
> 
>> figured it might be desirable to allow an installer to take an upstream
>> library, together with its .asd file, and modify only his/her version of
>> find-system so that when <library>.asd was loaded, we would also look
>> for (for example) <library>.install or <library>.config, and load those
>> right after the .asd file to impose any necessary site-specific
>> configuration.
> 
> I'm opposed to adding number of files responsible for the behaviour of
> the system as long as there are alternatives. They make debugging
> harder, and test case reproduction doubly so -- especially when they
> can contain arbitrary code.
> 

I guess that this is a matter of aesthetics, about which we'll have to
agree to disagree.  I think small snippets of code that are located
close to the things that they are supposed to configure are easier to
track, understand, and even test than stuff that's squirreled away
non-locally (e.g., in /usr/local/etc/sbclrc).

I think there are a a couple of facts about what I'm doing, and how it
differs from what you are doing that may make for this difference of
opinion.

I'm concerned with delivering applications, rather than delivering a
lisp implementation, which seems more like your concern.

This means that I'm typically not messing with a site's global lisp
configuration, but rather local configurations.

I'm also often working with multiple lisp implementations concurrently,
which also leads me to see this as an issue of configuring the
individual libraries.

For that matter, I'm typically working with > 1 different lisp project,
in different lisp configurations (the projects have different source
repositories, assume different libraries, etc.).  So I typically work
with multiple different asdf:*central-registry* configurations.

At any rate, my idea is something that can be done easily within the
existing framework of ASDF, I believe, so it wouldn't interfere with
your ideas; it could coexist.