[asdf-devel] Proposal for improved support for versions of systems

[Robert Goldman]

On 6/28/10 Jun 28 -7:58 PM, Faré wrote:
>> Sorry, I've forgotten to address that.  I agree, that supporting full
>> Debian/RPM style versioning is better.  I'm not currently familiar enough
>> with that, so I will be thankful, if you point me to some good resource.
>>
> You can google for "rpm compare versions" and "dpkg compare versions"
> and things like that. You can also start with the lisp file attached,
> though it might not fit all the corner cases of the full specification
> (do you need to disambiguate if that function returns = ?).
> 
>> Well, when the DEFSYSTEM form is traversed and dependencies are loaded the
>> CURRENT implementation uses FIND-SYSTEM.  That is why I worked with
>> FIND-SYSTEM and not introduced some new construct to deal specifically with
>> versioned dependencies, because it would have duplicated the same code (in
>> case of not versioned ones — call FIND-SYSTEM, in case of versioned —
>> FIND-VERSIONED-SYSTEM?)
>>
> Any call site that doesn't use VERSION can keep calling FIND-SYSTEM,
> and any call site that does much use a new interface anyway, so can
> use a different function name as well as argument list.
> 
>>> That sounds both complex to implement, for little value to a user.
>>
>> It's already implemented, and the complexity you can judge for yourself.
>> Considering the value to the user, you might be right.  At least I'm not in
>> the position to judge.
>>
> As for the high-level design, see other paragraphs. As for low-level
> coding standards, here's what I can tell from a quick glance:
> 1- changing incompatibly VERSION-SATISFIES isn't nice either. Please
> provide functions like VERSION<= VERSION-MAJOR<=
> VERSION-MAJOR=-MINOR<= etc.
> 2- instead of #+mutest tests in same file, have a different file with tests.
> 3- (let ((*read-eval* t)) (defun ... #.blah ...) doesn't do anything
> useful. The let is evaluated at execute-time, the #. at read-time.
> 
>> Considering backwards incompatibility: there's no current API, I mean, those
>> functions are not part of the API but auxiliary functions used solely in
>> FIND-SYSTEM.
>>
> OK, so it's an internal interface. But if find-system from something
> straightforward becomes a monster that solves an NP-complete integer
> programming constraint problem, I fear we'll get more than we
> bargained for. And if it doesn't actually solve the version constraint
> problem, then it's a toy and I'd rather leave the problem to aptitude
> to solve. Up to now, ASDF has tried to remain simple, and I admit I
> did feel ambivalent about multiplying its size by three when I went
> from ASDF 1 to ASDF 2 (which did go noticed: at least janderson
> complained, and rightfully so).
> 
> I don't think proper versioning support that does the Right Thing(tm)
> can be added without making ASDF treble in size again, and so I'm
> reluctant to accept a solution that entails putting that in the basic
> ASDF, when what I think is a better solution can be achieved through a
> front-end that produces a proper source-registry, either on-line or
> off-line, but in any case, without growing the complexity of ASDF
> itself.
> 
>>> I propose instead that a completely different API be used, that computes
>>> and/or
>>> checks a source-registry from some specification and a database of
>>> available
>>> system versions. i.e. layer something on top of ASDF without modifying
>>> anything
>>> about ASDF proper.
>>
>> Yes, that is also possible.  It's just that currently ASDF has some
>> half-baked version support and it should be either removed completely
>> (deprecated) or improved up to usable state.  I mean, that all the versions
>> specified in current defsystem forms are hardly used by any software, that
>> might have wanted to utilize them, and that's because of poor current
>> implementation, I think.
>>
> My vote would be to deprecate and completely remove the current
> half-baked version support. I didn't do it earlier because it would
> have been a controversy that would only have delayed release of ASDF
> 2.0 without any major advantage. But now that the question is
> legitimately on the table, I definitely propose to get rid of that
> code.

I would vote against this.  Half-baked though it is, that version
support has been very helpful in maintaining multiple different versions
of software that I work with, and has trapped several dependency failure
errors that would otherwise have caused deeply cryptic errors when,
e.g., our unit testing framework was compiled against the wrong version
of Closer-MOP, when a large project was tested against the wrong version
of the unit test framework, etc.

The half-baked version support has been in ASDF since forever, and
ripping it out before providing a working replacement fails the
cost/benefit tradeoff:

Cost = a bunch of safeguards we rely on vanish.

Benefit = mild aesthetic satisfaction.

Please don't! ;-)

Best,
r