On 29 December 2014 at 06:58, Donald Stufft <donald@stufft.io> wrote:

The packaging lib currently does exactly that, given a specifier like >1.7 it

transforms it to >1.7 and !=1.7.*. The PEP even calls out the fact that a

maintenance release of the same series should not match and if you want it to

match then you should add a zero yourself.

Oops, I managed to drop the list off my reply to Donald. I won't relay the entire subsequent conversation, but the short version is:

* the current handling of ">" and "<" for maintenance releases in PEP 440 is incompatible with the previous behaviour of setuptools, which goes against one of the main guiding principles in the design of PEP 440 (we aimed to only break compatibility with pkg_resources when we had a really compelling reason)

* the interaction between the zero padding rules for the release segment and wildcard prefix matching is sufficiently tricky that both Donald and I got it wrong at various points in the discussion. When the two lead designers for an interoperability spec struggle to remember how it works in particular edge cases, that's a bad sign (that's not always avoidable, as some real world interoperability problems are just inherently confusing, but in this case we both now think it represents a genuine mistake in the PEP)

* as noted in the previous discussion, we have a short window before folks start shipping pip 6 with more slowly updating projects (like ensurepip and Linux distros) where we can treat PEP 440 as Provisional (even though PEP 1 doesn't officially include that notion yet). It makes sense to take advantage of that window, rather than locking in a design we've now realised we're not happy with.

* I was incorrect in thinking that ordering operations were currently defined purely in syntactic terms. They're already semantically aware, as they need to be to handle pre-releases correctly, so making them appropriately aware of post-release semantics is a smaller change than I thought

* for those cases (like date-based versions) where excluding releases with an additional numeric suffix is the right thing to do, an explicit prefix exclusion will still be possible, and will have the advantage of failing noisily on older versions of pip and easy_install, rather than silently installing an unexpected version (which is what will happen for anyone that starts relying on the current explicit exclusion in PEP 440). It's also possible to replace the exclusive bound with an inclusive bound that has the last release segment component incremented.