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:
- 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.
- :contingent-on dependency. Is this ticketed? Could we put a
ticket on launchpad about this?
- 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.
- 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.
- 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