On Tuesday, February 26, 2013 at 7:08 AM, Michael Foord wrote: > > > On 26 February 2013 03:22, Nick Coghlan <ncogh...@gmail.com > (mailto:ncogh...@gmail.com)> wrote: > > On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft <donald.stu...@gmail.com > > (mailto:donald.stu...@gmail.com)> wrote: > > > !=1.3 allowing 1.3.1 makes sense to me. 1.3 is equivalent to 1.3.0, 1.3.1 > > > != > > > 1.3.0. > > > > Nope, the PEP explicitly disclaims the historical equivalence between > > 1.3 and 1.3.0. It has to, because they're very different when it comes > > to what the PEP now calls a "compatible release clause" > > (http://www.python.org/dev/peps/pep-0426/#compatible-release), Ruby > > gems call a "pessimistic version constraint" > > (http://docs.rubygems.org/read/chapter/16#page74), PHP composer calls > > "next significant release" > > (http://getcomposer.org/doc/01-basic-usage.md#package-versions) and > > Node.js npm calls "Tilde version range" > > (https://npmjs.org/doc/json.html) (Note: I also checked CPAN version > > ordering to see if it had an equivalent operation, but Perl's approach > > appears to be closer to the way pkg_resources handles ordering: > > http://search.cpan.org/~jpeacock/version-0.9901/lib/version.pod#How_to_compare_version_objects) > > > > However, while numeric maintenance releases are part of the problem > > here, the real issue is correctly handling *post* releases. > > > > Does "== 1.3" allow "1.3.post1"? Does "!= 1.3" allow "1.3.post1"? Both? > > Neither? > > > > If you use strict string matching for == and !=, then "!= 1.3" will > > allow "1.3.post1", which is utterly insane given the PEP's recommended > > usage of post releases solely for non-functional changes like tweaking > > the release notes or project metadata. > > > > Leaving == as strict and making != prefix based breaks the fundamental > > relationship between equality and inequality checks, so that's also > > not a reasonable option. > > > > That leaves making both == and != prefix based as the most reasonable > > alternative, as "!= 1.3" will then correctly reject "1.3.post1" and > > the appropriate logical relationship is maintained between the two > > operators. > > > > However, you then need a way to spell an *exact* version request (for > > use with tools like zc.buildout and pip freeze that are designed to > > snapshot an application configuration rather than for dependency > > publication in an index). > > > > The current tools are strict with regards to equality - and in dependency > pinning I would see it as *surprising* that specifying "==1.3" installs some > version that isn't precisely 1.3. Having "==" mean approximately-equal, > instead of the-same-as, seems like a mistake to me. > > Michael I agree with this, == should mean EXACTLY 1.3, != should mean EXACTLY NOT 1.3.
However because these aren't strings and are versions we can understand that: 1.3 == 1.3.0 == 1.3.0.0 == 1.3.0.0.0 etc etc. > > > > My plan for that use case is to allow "is" as a comparison operator > > that means exactly what it says: the version required is precisely the > > specified version, with no prefix matching or release compatibility > > assessments allowed. > > > > That gives a natural progression in dependency constraints from more > > permissive to less permissive: > > > > Compatible version: some-dist (X.Y) # roughly equivalent to (>= > > X.Y, < X+1.dev0) > > Version equality: some-dist (== X.Y) # roughly equivalent to (>= > > X.Y, < X.Y+1.dev0) > > Version identity: some-dist (is X.Y) # must be exactly X.Y > > > > All three clauses also have clearly defined use cases: > > > > 1. Use compatible version clauses in published metadata for stable > > dependencies with a good backwards compatibility policy > > 2. Use version equality clauses in published metadata for dependencies > > without a good backwards compatibility policy > > 3. Use version identity clauses for application and deployment > > dependency snapshots > > > > Cheers, > > Nick. > > > > -- > > Nick Coghlan | ncogh...@gmail.com (mailto:ncogh...@gmail.com) | > > Brisbane, Australia > > _______________________________________________ > > Distutils-SIG maillist - Distutils-SIG@python.org > > (mailto:Distutils-SIG@python.org) > > http://mail.python.org/mailman/listinfo/distutils-sig > > > > -- > http://www.voidspace.org.uk/ > > May you do good and not evil > May you find forgiveness for yourself and forgive others > May you share freely, never taking more than you give. > -- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
