Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
I have posted the problem description together with possible solutions to the moptilities and closer-mop projects: https://github.com/gwkkwg/moptilities/issues/1 http://sourceforge.net/p/closer/mailman/message/31656992/
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
OK, so we clarified what happened with :version dependencies semantics. Now we can think what should we do with the failures, if we should. Note, the load failures do not happen with the most recent version of ASDF. Only with elder versions (which are still deployed together some Lisps, including the last releases of ECL, CLISP, CCL). The ASDf systems depending on moptilities: "hu.dwim.perec" "hu.dwim.perec+hu.dwim.quasi-quote.xml" "hu.dwim.perec+iolib" "hu.dwim.perec+swank" "hu.dwim.perec.all" "hu.dwim.perec.oracle" "hu.dwim.perec.postgresql" "hu.dwim.perec.sqlite" "metacopy" "metacopy-test" "metacopy-test-with-contextl" "metacopy-with-contextl" "metatilities" "metatilities-test" "moptilities-test" "simple-blog" "tinaa" "tinaa-test" "weblocks" "weblocks-clsql-demo" "weblocks-demo" "weblocks-demo-popover" "weblocks-elephant" "weblocks-elephant-demo" "weblocks-memory" "weblocks-postmodern" "weblocks-prevalence" "weblocks-s11" "weblocks-store-test" "weblocks-stores" "weblocks-test" "weblocks-tree-widget" "weblocks-util" "weblocks-utils" "weblocks-yarek" "weblocks-yui" I wonder, what exactly the moptilities author meant when declared :depends-on ((:version :closer-mop "0.55"))) - did he mean moptilities should only load with closer-mop 0.55? - or he meant only with closer-mop version >= 0.55? - or he meant moptiltiies should only load with closer-mop version "API compatible with 0.55" - or he didn't want to affect the asfd:load-op at all and just meant the declaration as a hint for the user? I must say I am surprised ASDF implements some dependency version management. It is not a widely known feature. I have even checked ASDF manual from 2009-08 http://web.archive.org/web/20090801104323/http://common-lisp.net/project/asdf/manual.html , 7 month after moptilities introduced the :version dependency. The manual says: "the :version, :author, description and other [defsystem] fields are not required but they provide documentation and information for people that want to use this system. It also says in the section about asdf:operate: "If a version argument is supplied, then operate also ensures that the system found satisfies it using the version-satisfies method." >From some other places in the manual we can even guess how version-satisfies >work. Still, I think it was too much to expect from closer-mop to encode API compatibility information in the version identifier. Note also, in 2009 ASDF didn't consider version "0.6" as satisfying requirement for "0.55": http://lists.common-lisp.net/pipermail/moptilities-devel/2009-December/date.html So, I think maybe the best fix is to remove :version from the dependency specification in metatilities.asd Also, as we speak about versioning, I have been trying to use semantic versioning as described at http://semver.org/ and I don't think it is a silver bullet - it doesn't solve all problems. Best regards, - Anton
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
> On 18 Nov 2013, at 16:45, Faré wrote: > > On Mon, Nov 18, 2013 at 10:21 AM, Pascal Costanza wrote: >>> ASDF is not going to hard code an >>> exception for your library. >> >> Closer to MOP already existed before asdf imposed anything on version >> numbers, so asdf has to provide a way to define exceptions for such cases. >> The versioning scheme of Closer to MOP was ad hoc, because nothing existed >> that could have been adhered to. It must be possible for libraries to move >> from non-adhering to adhering in a smooth way. Frankly, I don't care how >> that's achieved. If I can solve this by adding something to the system >> definition, that's fine with me... > Did your library exist on 20/02/2002? Because that's when > version-satisfies appeared with its ldo.so-like versioning semantics. The it was my mistake that I didn't pay attention, and just got lucky that it only created a problem two times in almost ten years... Pascal > . > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > Everyone hates a martyr. It's no wonder martyrs were burnt at a stake. >— E.W. Howe, "Country Town Sayings", p.7
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
On Mon, Nov 18, 2013 at 10:21 AM, Pascal Costanza wrote: >> ASDF is not going to hard code an >> exception for your library. > > Closer to MOP already existed before asdf imposed anything on version > numbers, so asdf has to provide a way to define exceptions for such cases. > The versioning scheme of Closer to MOP was ad hoc, because nothing existed > that could have been adhered to. It must be possible for libraries to move > from non-adhering to adhering in a smooth way. Frankly, I don't care how > that's achieved. If I can solve this by adding something to the system > definition, that's fine with me... > Did your library exist on 20/02/2002? Because that's when version-satisfies appeared with its ldo.so-like versioning semantics. To go back to actually looking for a solution (which I understand you don't care for), we could either have subclasses of system with different methods on version-satisfies, or we could have a :version-satisfies slot in system, that defaults to one of 'version-compatible-p or 'version<= (for the old and new behavior respectively), and asdf itself would specify the current version<= behavior for itself if it isn't the default. Note however that using either :class system-using-version<= or :version-satisfies version<= is not itself backward-compatible with old versions of ASDF, and so will have be protected with #+asdf3.1 or some such. Personally, I wouldn't go through that trouble, and would stick to the current lexicographic-only version comparison, because I think the ld.so semantics don't really apply to source compatibility. But doing something is Robert's prerogative now. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everyone hates a martyr. It's no wonder martyrs were burnt at a stake. — E.W. Howe, "Country Town Sayings", p.7
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
> On 18 Nov 2013, at 15:54, Faré wrote: > >> On Mon, Nov 18, 2013 at 2:34 AM, Pascal Costanza wrote: >> The 0.xy versions of Closer to MOP were not based on semantic versioning, >> but on an ad hoc versioning scheme. 1.0.0 did not change any API at all, so >> is definitely compatible with the last 0.xy versions. 1.0.0 is supposed to >> acknowledge the maturity of the library, that's it. >> >> The FAQ section at http://semver.org seems to suggest that exceptions to the >> rules are acceptable, and I believe that a change from ad hoc version >> numbers to semantic versioning is such an exception. >> >> I'm open to suggestions for a better solution. > You're not proposing a solution. Indeed, because I don't know what a good solution could be. > ASDF is not going to hard code an > exception for your library. Closer to MOP already existed before asdf imposed anything on version numbers, so asdf has to provide a way to define exceptions for such cases. The versioning scheme of Closer to MOP was ad hoc, because nothing existed that could have been adhered to. It must be possible for libraries to move from non-adhering to adhering in a smooth way. Frankly, I don't care how that's achieved. If I can solve this by adding something to the system definition, that's fine with me... Pascal > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > Thinking is the hardest work there is, which is probably the reason why > so few engage in it. — Henry Ford
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
18.11.2013, 08:02, "Robert P. Goldman" : > Anton Vodonosov wrote: > >> 18.11.2013, 07:50, "Robert P. Goldman" : >>> Are you saying now that version 1.0.0 of Closer-MOP will satisfy the >>> requirement of 0.55, and that Anton should *not* be having this build >>> failure. >> Robert, build failures happen on older ASDF, and not happen on newer ASDF. > > Well this certainly was not an ASDF change I was consulted about or approved > of. It has happened right before ASDF maintenance was transferred to you, maybe even during the transition. See the mailing thread mentioned by Xach: http://thread.gmane.org/gmane.lisp.asdf.devel/3062/focus=3066 >From this thread I understand that ASDF uses the same version-satisfies for determining compatibility between ASDF versions, and for determining if an ASDF system satisfies the :depends-on ((:version ...)).
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
On Mon, Nov 18, 2013 at 2:34 AM, Pascal Costanza wrote: > The 0.xy versions of Closer to MOP were not based on semantic versioning, but > on an ad hoc versioning scheme. 1.0.0 did not change any API at all, so is > definitely compatible with the last 0.xy versions. 1.0.0 is supposed to > acknowledge the maturity of the library, that's it. > > The FAQ section at http://semver.org seems to suggest that exceptions to the > rules are acceptable, and I believe that a change from ad hoc version numbers > to semantic versioning is such an exception. > > I'm open to suggestions for a better solution. > You're not proposing a solution. ASDF is not going to hard code an exception for your library. Though it's possible to override the ASDF default behavior, the library itself would have to do it, and there still needs to be an ASDF default, and the question is which. The ASDF default changed in 3.0.1, for practical reasons having to do with an issue with ASDF itself, and making the smallest change during a crisis. It can change back (in which case a non-default class or initarg would be used for ASDF itself). The discussion is about what the default should be, and what should be the means to override it if necessary. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Thinking is the hardest work there is, which is probably the reason why so few engage in it. — Henry Ford
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
The 0.xy versions of Closer to MOP were not based on semantic versioning, but on an ad hoc versioning scheme. 1.0.0 did not change any API at all, so is definitely compatible with the last 0.xy versions. 1.0.0 is supposed to acknowledge the maturity of the library, that's it. The FAQ section at http://semver.org seems to suggest that exceptions to the rules are acceptable, and I believe that a change from ad hoc version numbers to semantic versioning is such an exception. I'm open to suggestions for a better solution. Pascal Sent from my iPad > On 18 Nov 2013, at 04:50, "Robert P. Goldman" wrote: > > Wait, what? > > Are you saying now that version 1.0.0 of Closer-MOP will satisfy the > requirement of 0.55, and that Anton should *not* be having this build > failure. > > Because I don't think it *is* a bug. > > If someone releases version 2.0 of a software package, and I have a > library that relies on version 1.x, I *want* to be warned that the API > has moved under me. > > For that matter, if a library has been unmaintained for three years (I'm > talking about you, moptilities!) while its dependencies have moved under > it, I would like to be warned that it's likely not to be working. > > I'm willing to see some special-purpose kludge to break this for the > ASDF upgrade case, because we have set things up so that ASDF upgrades > should work whenever one version is greater than another. > > Even for ASDF, code that relied on old versions of the ASDF API should > not be fooled into thinking that it will be forward compatible. That's > why I insisted on bumping to ASDF 3 to reflect the fact that the API had > changed. > > MOPTILITIES *should* break under the current circumstances; that's not a > bad thing. Either someone should look and see if it's compatible with a > new version of Closer-MOP and take the 2.4 seconds required to bump the > :VERSION dependency, or if it's not worth anyone's time to do that, > maybe it's not a library that people should be using, and it should get > garbage-collected from the community. > > Best, > r >
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
18.11.2013, 07:50, "Robert P. Goldman" : > Are you saying now that version 1.0.0 of Closer-MOP will satisfy the > requirement of 0.55, and that Anton should *not* be having this build > failure. Robert, build failures happen on older ASDF, and not happen on newer ASDF.
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
Wait, what? Are you saying now that version 1.0.0 of Closer-MOP will satisfy the requirement of 0.55, and that Anton should *not* be having this build failure. Because I don't think it *is* a bug. If someone releases version 2.0 of a software package, and I have a library that relies on version 1.x, I *want* to be warned that the API has moved under me. For that matter, if a library has been unmaintained for three years (I'm talking about you, moptilities!) while its dependencies have moved under it, I would like to be warned that it's likely not to be working. I'm willing to see some special-purpose kludge to break this for the ASDF upgrade case, because we have set things up so that ASDF upgrades should work whenever one version is greater than another. Even for ASDF, code that relied on old versions of the ASDF API should not be fooled into thinking that it will be forward compatible. That's why I insisted on bumping to ASDF 3 to reflect the fact that the API had changed. MOPTILITIES *should* break under the current circumstances; that's not a bad thing. Either someone should look and see if it's compatible with a new version of Closer-MOP and take the 2.4 seconds required to bump the :VERSION dependency, or if it's not worth anyone's time to do that, maybe it's not a library that people should be using, and it should get garbage-collected from the community. Best, r
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
> Anton Vodonosov wrote: >> So, my question is: how :depends-on ((:version ...)) >> should work, and is the change in the behavior intentional? > The change of behavior in VERSION-SATISFIES is from ASDF 3.0.1, 2013-05-16. Since even before VERSION-SATISFIES was introduced on 20/02/2002, ASDF had been considering that different major version number signified incompatibility. I lifted that restriction, and made the check be the simple lexicographic order comparison it otherwise was, after parsing. Parsing is still separating the version into a list of non-negative integers; leading zeroes don't count. The reason for the change is that when releasing ASDF 3.0.0, we found that this caused an issue with ASDF itself considering that it was not compatible with ASDF 2; therefore Quicklisp considered ASDF 3.0.0 was not an adequate replacement for ASDF 2.26, and tried to load ASDF 2.26 on top of ASDF 3.0.0, with catastrophic results. Therefore, after briefly consulting the ASDF user base, and checking that not one of the quicklisp projects was positively relying on the old behavior, I quickly released a new ASDF 3.0.1, where a greater major version number only means more awesomeness in a compatible way. It seems that the old behavior had never been documented, except for the source code itself, and its being mentioned on this mailing list when the semantics of versions was previously discussed. Hence no one relying on it. Apologies for the breakage. On Sun, Nov 17, 2013 at 9:01 PM, Robert P. Goldman wrote: > There are two different version requirements. > > :version is supposed to be "this is the version I need." It treats > changes in the highest version component as API-changing modifications > that don't satisfy requirements for mismatching major components. > > When we advertise Closer-MOP 1.0.0, we are saying that we have made > changes to the API, so it's different from 0.x. Hence a :VERSION > dependency of 0.55 is not satisfied by 1.0.0, although it IS satisfied > by 0.61 > > If major changes are going on in a library's API, then they should be > noted by the library developer, and people who use this library have to > think about those changes. This is unavoidable and better than dealing > with versioning systems like where you never know when a library's API > has changed, and your code may break at the slightest version bump. > > Actually I think that the code may have changed to be more permissive at > some point. I believe that originally a requirement of, e.g., 0.0.7 > would not be satisfied by 0.1.0 (although it would be satisfied by 0.0.9). > > The good news is that ASDF's version numbering scheme has a semantics > that can provide useful support to programmers. The bad news is that > not enough people know about this semantics, so it doesn't provide as > much value as it might. > Robert correctly describes the old behavior of ASDF 1 & 2, that was discontinued in ASDF 3. Dan Barlow was obviously inspired by the number versioning of Linux shared object libraries. It seems this wasn't how the CL community started using these version numbers. And the match was probably not that great: Linux .so's involve object-level compatibility, whereas ASDF dynamic loading involves source-level compatibility, where compatibility if desired can be handled with #+ and #. and conditionals with find-symbol or fboundp. Meanwhile, we use output-translations to deal with object-level incompatibilities. Overall, the old behavior of version-satisfies is not to be regretted, and the new maintainer may once again consider adopting (or not) the rpm or debian or whatever other version comparison mechanism (in which case I can submit code I once wrote). But hey, Dan Barlow was a great experimenter; some of his experiments failed, others succeeded brilliantly; thanks Dan. > One thing that might make everyone's lives easier would be making the > MISSING-DEPENDENCY-OF-VERSION error a continuable error instead of a > fatal one. What would you think about this? > That can do it. On the other hand, if the author inserted a :version requirement, he probably had a good reason, and it's therefore vain to try to override it, rather than upgrade the library. PS: unrelatedly, there has been a lot of action on ASDF since 3.0.3: * There is my package-system one-package-one-system-per-file support, compatible with quick-build and similar to faslpath. * A lot of UIOP fixes, notably as it's now being used in the Google build system (short-circuiting the asdf/defsystem itself, instead using a converter from ASDF to the native system to which Lisp support was added). * ASDF will soon support GCL (Camm Maguire has released 2.6.8 and 2.6.9 and is now actively fixing the bugs in GCL that prevented ASDF from running, while I've been modifying ASDF itself). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Never explain. Your friends do not need it and your enemies will never believe you anyway. — Elb
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
Anton Vodonosov wrote: > So, my question is: how :depends-on ((:version ...)) > should work, and is the change in the behavior intentional? There are two different version requirements. :version is supposed to be "this is the version I need." It treats changes in the highest version component as API-changing modifications that don't satisfy requirements for mismatching major components. When we advertise Closer-MOP 1.0.0, we are saying that we have made changes to the API, so it's different from 0.x. Hence a :VERSION dependency of 0.55 is not satisfied by 1.0.0, although it IS satisfied by 0.61 If major changes are going on in a library's API, then they should be noted by the library developer, and people who use this library have to think about those changes. This is unavoidable and better than dealing with versioning systems like where you never know when a library's API has changed, and your code may break at the slightest version bump. Actually I think that the code may have changed to be more permissive at some point. I believe that originally a requirement of, e.g., 0.0.7 would not be satisfied by 0.1.0 (although it would be satisfied by 0.0.9). The good news is that ASDF's version numbering scheme has a semantics that can provide useful support to programmers. The bad news is that not enough people know about this semantics, so it doesn't provide as much value as it might. One thing that might make everyone's lives easier would be making the MISSING-DEPENDENCY-OF-VERSION error a continuable error instead of a fatal one. What would you think about this? Cheers, r
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
This is caused because in older ASDF, a version of 1. was not considered to satisfy a version requirement of 0.. This was changed because ASDF updated to 3.0 but was not considered satisfying 2. as required by Quicklisp. http://thread.gmane.org/gmane.lisp.asdf.devel/3062/focus=3066 has some info about when and why this was changed. Zach Pascal Costanza writes: > Hi, > > I’m the maintainer of Closer to MOP, and I have just updated the version > numbers as you describe below. If I made a mistake and chose a numbering > scheme that confuses ASDF, please let me know, and I will fix this. However, > I believe what I chose is in line with the ASDF documentation. > > Previously, the version numbers for Closer to MOP lacked a third entry > (“patch version”), maybe this is a confusing change? > > Pascal > > On 17 Nov 2013, at 10:34, Anton Vodonosov wrote: > >> Hello. >> >> Has the semantics of :depends-on with :version >> specified for the dependency changed recently? >> >> I am asking, because I observe problems in several libraries. >> >> For example, moptilities. >> >> moptilities.asd has :depends-on ((:version :closer-mop "0.55")) >> >> In Quicklisp 2013-11-11 closer-mop is updated, now its ASDF >> system has :version "1.0.0" >> >> Now moptilities fails to load on many lisps >> (clisp, ccl-1.8, ccl-1.8, ecl, sbcl-1.1.0.36). >> >> The error is MISSING-DEPENDENCY-OF-VERSION: >> Component :CLOSER-MOP does not match version 0.55, required by #> "moptilities"> >> >> But on sbcl-1.1.11 moptilities load OK. >> This is a relatively recent SBCL, so I assume >> it has newer ASDF than many other lisps. >> And probably that's why it it can load moptilities. >> >> Also interesting, that in the previous Quicklisp >> closer-mop version was "0.61". And moptilities, >> which depend on closer-mop "0.55" was loaded successfully >> by many lisps which now fail. >> >> Test results for moptilities for the current and previous >> Quiclisp may be found here: >> http://common-lisp.net/project/cl-test-grid/library/moptilities.html >> >> Moptilities is only on example, there are other libraries >> affected by this problem. >> >> So, my question is: how :depends-on ((:version ...)) >> should work, and is the change in the behavior intentional? >> >> Best regards, >> - Anton >> >> >> >> >> >> >> > > -- > Pascal Costanza
Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
Hi, I’m the maintainer of Closer to MOP, and I have just updated the version numbers as you describe below. If I made a mistake and chose a numbering scheme that confuses ASDF, please let me know, and I will fix this. However, I believe what I chose is in line with the ASDF documentation. Previously, the version numbers for Closer to MOP lacked a third entry (“patch version”), maybe this is a confusing change? Pascal On 17 Nov 2013, at 10:34, Anton Vodonosov wrote: > Hello. > > Has the semantics of :depends-on with :version > specified for the dependency changed recently? > > I am asking, because I observe problems in several libraries. > > For example, moptilities. > > moptilities.asd has :depends-on ((:version :closer-mop "0.55")) > > In Quicklisp 2013-11-11 closer-mop is updated, now its ASDF > system has :version "1.0.0" > > Now moptilities fails to load on many lisps > (clisp, ccl-1.8, ccl-1.8, ecl, sbcl-1.1.0.36). > > The error is MISSING-DEPENDENCY-OF-VERSION: > Component :CLOSER-MOP does not match version 0.55, required by # "moptilities"> > > But on sbcl-1.1.11 moptilities load OK. > This is a relatively recent SBCL, so I assume > it has newer ASDF than many other lisps. > And probably that's why it it can load moptilities. > > Also interesting, that in the previous Quicklisp > closer-mop version was "0.61". And moptilities, > which depend on closer-mop "0.55" was loaded successfully > by many lisps which now fail. > > Test results for moptilities for the current and previous > Quiclisp may be found here: > http://common-lisp.net/project/cl-test-grid/library/moptilities.html > > Moptilities is only on example, there are other libraries > affected by this problem. > > So, my question is: how :depends-on ((:version ...)) > should work, and is the change in the behavior intentional? > > Best regards, > - Anton > > > > > > > -- Pascal Costanza
