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