Re: Proposed ASDF modification

>>>>> "NS" == Nikodemus Siivola <[email protected]> writes:

    NS> [email protected] writes:
    >> Since we can require particular versions of software, it seemed
    >> to me that we should also be able to say stuff like:
    >>
    >> (asdf:oos 'asdf:load-op :shop2 :version "1.3.0")

    NS> There are several gotchas with this, but most importantly:
    NS> what happens if you try to load both "1.2.0" and "1.3.0"?

    NS> Answer: bad things, at least unless the author has arranged
    NS> for different versions of his software to live in different
    NS> packages.

    NS> What if author A has gone to the trouble required for
    NS> different versions to coexist? How can she specify that "1.0"
    NS> thru "1.1" conflicts with "1.2", but that anything after that
    NS> can coexist?

    NS> How many systems "out there" use :version that is a string of
    NS> three (or less) dot-separated numbers, or can be parsed as
    NS> such? What about things like "1.test-release"?

    NS> Furthermore, since most real systems are being loaded by other
    NS> systems using :depends-on, it should be possible to use that
    NS> to specify version X too.

Most of these are not issues that are raised by my proposed patch.

To go in reverse:

1.  You can already use :depends-on to specify a version number,
    although this is not clearly spelled out in the ASDF manual.
    Here's a snippet from the defsystem of Gary King's TINAA system
    that he and I worked out together:

  :depends-on ((:version "defsystem-compatibility" "0.1")
               (:version "metatilities" "0.3")
               lml2

2.  The ASDF manual specifies that versions MUST be strings of
    dot-separated numbers that can be parsed as such.  This actually
    *is* documented, and "1.test-release" defies the ASDF
    documentation.

    [One issue that I stumbled on is that 1.3 < 1.3.0, which seems
    wrong to me...]

3.  Version coexistence is an unsolved problem.  Indeed, as far as I
    can tell, you can only specify a dependency that is version >=, so
    you cannot do some of the things that you refer to earlier.

4.  ASDF does not seem to consider the possibility of multiple
    versions of a library coexisting.  But this is not a problem of
    my making; it existed before I wrote this patch and it will exist
    no matter what happens, since the :depends-on already raises this
    problem.

    My personal belief is that ASDF for CL needs some method like
    "static linking" that would allow you to pull in a library without
    upsetting your environment.  I pass this issue on to wiser heads.


    NS> Now, while a relatively complete solution "for all this" is
    NS> probably not in scope for ASDF, as it would have to include
    NS> either versioned packages or package naming conventions, etc,
    NS> I can be persuaded that the minimal ability for ASDF systems
    NS> to specify which version of another system they expect would
    NS> be a good thing.

This facility is already present although not documented.

    NS> * If trying to load another version (when one has already been
    NS>   loaded) signal a continuable error.

This is not really

    NS> * :DEPENDS-ON should support things like ("FOO" :VERSION ...)
    NS>   and ("FOO" :MIN-VERSION) in addition to plain "FOO".

It seems to support only :version (which has the semantics of
:min-version).  There is no :version= in ASDF.

    NS> * VERSION= and VERSION<= should deal with "1.2.foo" and
    NS>   "2.bar", but punt on things like "1.beta.2.foo" -- possibly
    NS>   signaling an error.

This violates the current specification, but could probably readily be
added by anyone who wishes to hack on asdf:version-satisfies.

    NS> * This definitely needs to be documented: the nuts and bolts
    NS>   need to be described and a "best practises" document would
    NS>   be good too for real interoperability to emerge.

Yes.  Indeed a first step (as witness your questions) will be to get
the documentation updated so that it reflects current reality; then we
can move on to further refinements.

Best,
R


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642