On Tue, Jun 29, 2010 at 1:00 AM, Faré fahree@gmail.com wrote:
: Faré
: Vsevolod Dyomkin Dear
If I may suggest a simpler, cheaper and more useful strategy for helping with the version management of Lisp software, it would be to automatically produce Debian, RPM or Nix packages from ASDF specifications, and let those tools do the rest of the integration.
I reiterate my suggestion.
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.
Why only three integers? While you're at it, why not accept the whole range of Debian or RPM version comparisons?
Actually, the number of integers is not limited, it's just that this is
the
default practice and currently available predicates only take into
account
the first two. So the internal representation is a list of integers.
But
the user can specify versions in many different formats, like "1.2.3" or even 1.2 (float number). Moreover it's possible to build adapters for
more
representations by defining methods for the generic function
PROPER-VERSION.
Once again, it would be better if you just agreed to the de facto "standard" of either Debian or RPM versioning. But once again, I think this code should NOT be part of ASDF.
To clarify my point: there are cases of libraries, that use the read-eval syntax in version definitions, most notable of which are Edi Weitz's and Cyrus Harmon's. I agree here with Robert Goldman, that this is a little contrary to the declarative nature of DEFSYSTEM form. Still it is not a problem with neither the existing, nor the proposed variants. It's just that in the FIND-SYSTEM pipeline such version declarations (or rather evaluations) won't be counted (i.e. considered equal to wildcard
version).
But during the evaluation of DEFSYSTEM form itself the version would be properly evaluated. So this peculiarity will effect the new behavior,
but
not the old, that is why I don't consider it a problem: if someone would like to use the new behavior, he is free to adapt his code, otherwise he
can
leave it as is and no problems would arise.
That I agree with. We should be sure to provide a simple incremental upgrade path from where we are to wherever we go.
Besides, an incompatible change is introduced to FIND-SYSTEM. The ERROR-P optional argument is removed, so plain NIL is unconditionally
returned,
when system is not found, and VERSION and VERSION-P optional arguments are added instead.
This sounds very bad to me. What is the use case?
The use case is that we can now (oos 'load 'system :version "1.2.3") or write in defsystem :depends-on (system "1.2.3" :above). As all those user-facing facilities use FIND-SYSTEM as the underlying tool. Independently from adding VERSION and VERSION-P I would still argue to remove ERROR-P argument, as it adds unnecessary complexity. There's only one place in the original ASDF code (OPERATE), where it's expected and it
is
easily handled in the caller.
This is not a use case. What is a high-level situation in which a user or developer may want to use versioning, and why should this situation be solved using FIND-SYSTEM?
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?)
How does that affect the semantics of find-system? Can there now be many instances of a system in the source-registry?
The semantics is the following: only zero or one instance of a system
with a
particular name can be in memory (in *defined-systems*) — just like
before.
The current behavior is that if some system is loaded, there's no possibility to load the new version. The new behavior is that, if FIND-SYSTEM is forced to load the different version of the system, a continuable error is signaled, that informs the user of the situation and it's possible either to abort or continue. If the user continues, the
new
definition is loaded instead of the old.
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.
Does find-system now have to grovel for *all* these instances, load the .asd files to determine the version and pick the most recent one by default? That's C R A Z Y.
Yeah, now SYSDEF-CENTRAL-REGISTRY-SEARCH et al. return a list of found
ASD
files instead of the first one. Then the most suitable is chosen by
these
criteria:
- if no version is specified it will be either the one already in memory,
or
the first one in the list
- if version is specified it will be the one in memory, if
VERSION-SATISFies, or the first from a list, for which version satisfies
That's both expensive and backwards incompatible with current API.
Yes that's expensive, but it can be mitigated. Considering backwards incompatibility: there's no current API, I mean, those functions are not part of the APIm but auxiliary functions used solely in FIND-SYSTEM.
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.
Note that the current interface of find-system seems to be copied from that of find-class.
Hmm, I see. I still don't support such decision, but maybe I just not understand something...
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.
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'd rather ASDF has only one test framework, if possible one with few dependencies if at all.
I agree. If there's one already chosen, I'll stick to it. as I've said, when I've started this work, I didn't find any tests, so I used my own approach. By the way MUTEST is dependency-free.
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)...
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I once dreamt that children would be taught to not accept slogans on face value, but to see through words and look for meaning or lack thereof. However, I soon realized that by the time schools teach this piece of wisdom, it may have itself become a slogan devoid of meaning, the sense of its words having drifted or been otherwise corrupted by time and vice. You need more than dead words to have people think by themselves; you need a living tradition.