[Distutils] PEP440: >1.7 vs >=1.7

[Nick Coghlan]

On 29 December 2014 at 06:58, Donald Stufft <donald at 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.

Next steps:

* I'll update the currently published version of PEP 440 to include a note
regarding its provisional status
* Donald is going to put together a PR to update the interoperability spec
to match the semantics of his proposed change to the packaging library
(that will either be in the existing BitBucket repo, or after moving the
drafts to the new GitHub repo)
* I'll write a new PEP proposing some changes to PEP 1 based on the things
we found challenging in bringing PEP 440 to a close (this is the first PEP
completed under the new delegation of authority model, and we've definitely
found some rough edges that could stand to be smoothed out)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141229/e73a5edd/attachment.html>