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

[Faré]

> 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.

>> It's just a matter of backwards compatibility. If we're going to change
>> how
>> things work, I'd rather we provide a new API and declare the old one
>> obsolete
>> than break backwards compatibility gratuitously.
>
> Yes, I understand that. Well, actually, that is really not such a big issue,
> so FIND-SYSTEM can be left with the existing argument set (or, better,
> VERSION/VERSION-P arguments can be added to the tail of the optional list,
> which will be backwards compatible).  It was more a suggestion towards a
> more clear API (and it's possible to change it, as it seems, noone is using
> the current one :)  But I reiterate, that the issue is not critical at all.
>
I say, have a completely different function name with keyword
arguments. And make it part of a separate front-end system. First
implementation: export version information to dpkg format and use dpkg
to solve the constraints (or same with rpm, Nix, etc.).

>> Also, I'm not convinced by
>> this :VERSION interface. Version matching is not a local problem to be
>> solved by adding :VERSION arguments to local function calls, but a global
>> problem to be approached by collecting (in)equations about available
>> versions,
>> solving these inequations, and producing a source-registry (possibly
>> pointing
>> to a single generated link farm) as a solution.
>
> Your solution should also work.  But I believe (and my limited testing has
> confirmed that), that a local solution is also viable, because all the
> inequalities in our case boil down to the separate decisions, that can be
> taken only by the user himself to select, which of the conflicting versions
> of the system should be present in his image (as there can be only one
> simultaneously).  And, I think, that in most of the cases, the user will not
> take a decision actually, but just will be informed of the existing problem
> with dependencies.  Still, I can imagine some cases, where a decision can be
> taken: first of all, when it's possible to load a newer system; secondly, in
> a dynamic environment during experiments.
>
I still don't see a use-case for this interactive version-picking
activity. The problem we have is known as "DLL hell". It's not
something for which people want a half-assed "one question at a time"
maybe-solving interaction. It's something people don't want to be
doing at all. Either a solution has been found and delivered by
distribution maintainers (hopefully through automated testing of
candidate releases of combinations of the latest versions) and you
just use that, or you're a developer trying to fix an identified
problem with some recent version of a library that you want to use
because of a recent bug fix or feature. In no case does anyone want to
mix and match at random providing old versions one by one without
knowing whether they will work together.

>> I haven't looked at MUTEST yet. I'll have to do it soon. If you're willing
>> to migrate all existing tests to it -- why not.
>
> I will look at it.  I think, first of all, it depends on the question,
> whether I will need to do something with the current tests for versioning
> (i.e. will the be a need to integrate that piece of code into ASDF)...
>
Indeed. I don't know what others think, but I think your current code
isn't desirable in ASDF. I believe it's the wrong approach, trying to
salvage a doomed attempt at solving versioning through myopic
interfaces instead of meaningfully addressing the issue of doing
holistic version matching.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Every country has an army, either its own or a foreign one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: version.lisp
Type: application/octet-stream
Size: 1749 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100628/246e8bcc/attachment.obj>