[asdf-devel] :ASDF-DEPENDENCIES implemented

Robert Goldman rpgoldman at sift.info
Sun Apr 18 14:56:33 UTC 2010


On 4/18/10 Apr 18 -9:50 AM, Robert Goldman wrote:
> On 4/17/10 Apr 17 -4:08 PM, Juan Jose Garcia-Ripoll wrote:
>> It is a two-lines change that allows a defsystem form depend on a
>> package that provides additional functionality, such as new system
>> classes, new system options, new methods, etc.
>>
>> :ASDF-DEPENDENCIES ({system-name}*)
> 
> Suggest you also add :optional-dependencies
> 
> This would be for things like test libraries.  ASDF would make a best
> effort attempt to load these systems, but should be entitled to assume
> that they are optional and that it should be able to process the
> defsystem correctly without them, if losing some functions.
> 
> E.g., we have an asdf extension for our test library, ASDF-NST.  It
> would be nice if we could list that as an optional-dependency.  Our
> systems load correctly if you /don't/ have NST, but would behave better
> in the presence of ASDF-NST.

About 30 seconds additional thought suggests that optional-dependencies
is, well, suboptimal!  Suggest that this should be something more like
:optional-asdf-dependencies

Another point:  I'd like to suggest that a prerequisate for introducing
this new initarg should be a specification of its behavior in something
other than CL code:  in somewhat formal natural language that can be
adapted for the manual.

One of the things ASDF /desperately/ needs is a specification of its
protocols.  This is not a problem created by the addition of such new
features, but it is /exacerbated/ by adding new features.

So:  what is the intended effect of :ASDF-DEPENDENCIES and
:ASDF-OPTIONAL-DEPENDENCIES?  At what point in the processing of the
DEFSYSTEM are they processed?  How do they interact with the processing
of other DEFSYSTEM initargs?  The answers to these questions should not
be left to reading the code.

Best,
R




More information about the asdf-devel mailing list