Re: Re: Proposed ASDF modification

I strongly agree with the spirit of your patch Robert and thank  
Nikodemus for uncovering some of messy complexity that needs to be  
considered. I'll add to the discussion with the observation that  
"versioning is hard" <smile>.  Unfortunately, I don't have much more  
to contribute this morning...

On May 10, 2006, at 9:14 AM, [email protected] wrote:

>>>>>> "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
> _______________________________________________
> cclan-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cclan-list


-- 
Gary Warren King
metabang.com
http://www.metabang.com/
(413) 210 7511
gwking on #lisp (occasionally)




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