[asdf-devel] Last call before code freeze

[Robert Goldman]

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