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

Tue Jun 29 20:13:40 UTC 2010

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 at sift.info>wrote:

> 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>

-- 
vsevolod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100629/348447d1/attachment.html>