Robert,
That's why I've started developing this topic of improving version support in ASDF (and not elsewhere), because if versions need to stay there, they preferably should be only there to adhere to the DRY principle, and if they are only there, they need to be supported well :)
Yet, I agree with Faré, that it's much easier to perform dependency management separately, and, if we go further along this line, completely take it out of ASDF and leave ASDF just as a build tool. Although that is highly unlikely to happen :)
Cheers, Vsevolod
On Tue, Jun 29, 2010 at 11:07 PM, Robert Goldman rpgoldman@sift.infowrote:
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
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel