[asdf-devel] What is the release process for ASDF?

[Faré]

2009/12/1 Robert Goldman <rpgoldman at sift.info>:
>> Sure. Those of you who have patches you want included in the next
>> release, please re-send them to me, if possible based on my
>> development repo at
>>   http://common-lisp.net/project/xcvb/git/asdf.git
>
> OK, I will resend.
>
I got two small documentation patches from you that I committed to my
repo. I also committed tiny source documentation/comment fixes.

If no one speaks against what's in my repo, it will be pushed to the
official repo next week.

>> Actually, I'd even like to declare asdf:run-shell-command deprecated
>> copy it somewhere else for those who'd officially like to use it. A
>> cursory look at google/codesearch for "asdf:run-shell-program" finds
>> cclan, asdf-install which are readily fixable, but also a few others,
>> too. There might be some that are not indexed or import the symbol,
>> though.
>
> I would very much prefer that we not do this.
>
> Removing asdf:run-shell-command will break existing asd systems.  I
> have, for example, used asdf:run-shell-command as a portable means for
> running perl scripts and make inside ASDF system definitions.  I don't
> really think that google/codesearch is an adequate resource for
> assessing the danger of such breakage.  It certainly would only reveal
> O(1%) of my asdf system definitions, since many of my systems are not of
> general interest, and are only of use in my company, in a small group, etc.
>
> I would prefer a far more conservative approach to evolving ASDF, one
> that emphasizes not breaking existing systems.
>
Yes. My proposal was preposterous. I've added a comment in my repo
saying that I'd like it deprecated but that we'll support it until
there's a better solution AND everyone has had plenty of time to
migrate.

> I'm also concerned that you have talked about pushing stuff to contribs,
> but we don't yet have an announced plan for distributing such contribs.
> Do they just come with ASDF, or are they separate downloads?  I could
> possibly live with contribs that come in the distribution of ASDF, but
> separate downloads would not be acceptable.  Indeed, we have just taken
> a step in the other direction, rolling asdf-binary-locations into core ASDF.
>
My plan for contribs is that the ASDF distribution would come with its contribs
that have .asd files and that you can (asdf:load-system :asdf-blah)
assuming your asdf is itself properly loaded and configured.

> Two other issues:
>
> 1. ASDF does not have a graceful way of loading extensions.  We have
> just heard some complaints from Samium G about the way looking for a
> system definition can cause source code loading.  This is forced upon
> ASDF users by a limitation of the model.  There is no clean way for us
> to say "this ASDF extension is required by this system definition."  All
> we can do is put
>
> (asdf:oos 'asdf:load-op <my-asdf-extension>)
>
> in our .asd files....
>
> So every time we move a core function out of asdf, not only do we break
> existing systems, but we also make asdf less declarative and more
> imperative.
>
I think that it is the very design of ASDF that a .asd file is Lisp
source code, and that we thus reuse Lisp as the language to do magic
there. What better way to load extensions in your .asd than that?
After all, you need the extension there before you even try to parse
the defsystem statement with the loaded extension.

> 2. Existing ASDF extensions get stuffed into the ASDF package.  This
> seems like something that's likely eventually to cause us pain (as in
> "name collisions" and "method definition collisions").
>
> To do this gracefully, we must move in the direction of providing an
> ASDF-extender API.  For example, a package like ASDF-INTERNALS that
> exports a lot more of the ASDF symbols, and some more method combination
> hacks, like the one that allows ASDF to have "around" methods inside
> :around methods defined by ASDF users.
>
> In my opinion, such a careful, graceful treatment of ASDF unbundling
> would require more effort than we are likely to recoup in benefits.
> Certainly, it's not where I'd like to put my open source hours (but if
> others do, more power to you!).
>
Yup. I'd rather work on XCVB.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
If you're wrong against the dominant ideology, you'll be laughed at.
If you're right against the dominant ideology, you'll be hated.