Faré wrote:
2009/12/1 Robert Goldman rpgoldman@sift.info:
I just checked, and I see that my documentation patches have not been pushed. Any objection to pushing them before the release?
If you are willing to do that, I'd appreciate it. I prefer not to do anything irrevocable to the git repo....
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.
Note that now that we have an asdf.asd, I'd like to keep anything not necessary to bootstrap in separate systems -- though I could be convinced otherwise and will yield to majority opinion on anything regarding ASDF.
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.
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.
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.
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!).