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

[Vsevolod Dyomkin]

On Tue, Jun 29, 2010 at 1:00 AM, Faré <fahree at 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.
>



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