[Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new =?utf-8?Q?=7E=3D_?=operator

[Donald Stufft]

On Tuesday, February 26, 2013 at 7:08 AM, Michael Foord wrote:
> 
> 
> On 26 February 2013 03:22, Nick Coghlan <ncoghlan at gmail.com (mailto:ncoghlan at gmail.com)> wrote:
> > On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft <donald.stufft at gmail.com (mailto:donald.stufft at 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   |   ncoghlan at gmail.com (mailto:ncoghlan at gmail.com)   |   Brisbane, Australia
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org (mailto:Distutils-SIG at 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130226/2ac4d839/attachment-0001.html>