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.