On 4/29/10 Apr 29 -6:18 PM, Faré wrote:
: rpg
: dherring
It's not a blocker to not have good system-dependencies, as Daniel says. But given that, I think the blocker is that we should rip out the system-dependencies misfeature. It's not right yet, so we shouldn't ship it, and encourage people to use it.
Would it be possible to document this as an experimental feature? Say its busted, give an example why, and encourage people to suggest improvements? Insert a style-warning that triggers when people use it?
Trying to avoid code changes right before a release,
Yes, I'm wary of having to change code, then change it back, especially considering how painful it is to get all the bugs out every time.
Presumably this should be a single changeset to revert, yes? This is what our shiny new git repo is for, right?
Moreover, I'll argue that it's not the system-dependencies feature being deficient here, but the version feature being deficient. system-depends-on works fine, and does the job.
No, this really has nothing to do with the version feature. The deficiency is that we push the defsystem form through the lisp reader. That's why there are lots of cases that can't be helped by our new system-depends-on feature. The need to put (asdf:oos 'asdf:load-op <depended-on-system>) above the defsystem form (and not use system-depends-on) is forced on us because the defsystem goes through the lisp reader before we handle the system-depends-on argument.
As James pointed out, this means that stuff with packages will not be helped by this.
That suggests that the current approach, which is:
read it all once process the system-depends-on process the other initargs
won't get at the root of the system dependency problem. What we need instead is something like
slurp it without reading process the system-depends-on /then/ expose it to the reader (if we so choose).
I'd like to give this some thought before we lock ourselves into the first approach with as yet unconsidered problems of backward compatibility moving to the second.
Best, r