[Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator

[Michael Foord]

On 26 February 2013 03:22, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft <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



> 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   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  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/eafa380c/attachment.html>