[asdf-devel] Is this necessary in this form? Re: ASDF 1.501

[james anderson]

On 2010-02-02, at 16:13 , Robert Goldman wrote:


> [1-5] Possibly each of these should go in its own mailing list  
> thread and/or
> ticket.  The questions seem to be substantially policy ones, so  
> possibly
> for discussion on the mailing list.

before one tickets any of these issues, it would be good if they made  
sense.
the issue is the relation between core growth and support for  
configuration and upgradability.

> Can we split out some issues here?  I think there's a lot of good  
> stuff
> in this message, but having it all grouped together may not be  
> helpful:
>
> 1.  Growth of asdf.lisp
>
>   a.  desirable?

no, certainly no on this order.
i discount neither the need to upgrade[1], nor the use cases for  
site, application, and user configuration.
i am skeptical that they require a second configuration system.

> On 2010-02-02, at 16:38 , Pascal J. Bourguignon wrote:
>
>>
>> On 2010/02/02, at 13:46 , james anderson wrote:
>>> I never had a
>>> good feeling about a configuration system which introduced itself to
>>> the world with the conclusion "Hence, all in one file", and am ever
>>> less convinced that it needs to be that way.
>>
>> Are you complaining here from the developers of ASDF stand point  
>> of from the users of ASDF stand point?

from the point of view of someone who would like to be a user. of  
something simple.

>>
>> My understanding is that the single-file feature is a good thing  
>> for users of ASDF: they only have to download and LOAD a single  
>> file.  This is good.

i agree. my objection was to the logic rather than the utility. as it  
were, one criteria for my thought experiment was that the asdf.lisp  
should be able to stand alone. thus the probe-file contingency in the  
bootstrap function.[2]

>   b.  Should we be splitting the file up more?  This seems likely  
> to be
> helpful to diff, but would lead to one-time merge conflicts hard to  
> get
> through, so possibly should be carefully scheduled.

in the interest of simplicity, the asdf.lisp should be implement core  
functions only. taken to the extreme, this could be just enough to  
read and interpret a .asd file. which is demonstrably possible, but  
fails to meet the 'one-file' criteria which mr bourguignon  
reiterated. that is, given the pre-git version, there is little  
reason to take things out, but - once one has already set the goal  
that it bootstrap itself, little reason to put anything in.

>
> 2.  :contingent-on dependency.  Is this ticketed?  Could we put a  
> ticket
> on launchpad about this?
>
> 3.  graphing utility
>
>   a.  core asdf?  I'm inclined to think not.
>   b.  contrib to be packaged with asdf when distributed.  Seems  
> like an
> appealing alternative.
>
> 4.  hierarchical names:  this one isn't of central interest to me,  
> so I
> haven't reviewed it carefully.

the references to 2-4 (plus the patch file) were intended only to  
call out, that the bootstrap process was able to load a patch and  
integrate several extensions based on the .asd file. 2 does fill a  
gap in the dependency logic, but that status is not significant to  
this discussion.

>
> 5.  asdf-output-locations
>
>   a.  desirable?
>   b.  contrib versus integral
>   c.  configuration

i would very much like it to be an optional, configurable  
contribution rather than part of the core implementation.

-------
[1] http://github.com/lisp/net.comon-lisp.asdf/blob/master/ 
asdf.lisp#L205
[2] http://github.com/lisp/net.comon-lisp.asdf/blob/master/ 
asdf.lisp#L2383