[Distutils] PEP440 Version Specifier Syntax

[Donald Stufft]

On May 19, 2014, at 7:15 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 
> On 19 May 2014 23:44, "Donald Stufft" <donald at stufft.io> wrote:
> >
> > Currently PEP440 has a version specifier syntax like
> > ``foo (2,~=2,==2,!=2,>=2,<=2,>2,<2)``. This is a hold over from PEP 345 of
> > which I cannot locate a rationale for this change.
> 
> It's at least in part to reduce ambiguity when listing multiple dependencies as a list, rather than as line separated:
> 
> foo(~=2,!=2.3.x), bar(~=3,!=3.5.4.x)
> 
> That's why my initial reaction to the various aspects of the proposal was:
> 
> +1 to dropping the default comparison operator now we have "~=" as an explicit spelling
> +1 for dropping the space between the package name and the opening parenthesis (to be honest, I thought it was already at least optional , but the PEP may not make that clear)
> +0 for making the parentheses optional when only using a single comparison operator
> -0.5 for making the parentheses optional when using multiple comparison operators
> 
> On reflection, however, I'm switching back to "-1" for the latter two points. That's a UI issue for user facing formats that has no place in the data interchange specification. By contrast, the space is entirely redundant given the parentheses, so it makes sense to me to drop it from the interchange format. Allowing users to optionally include whitespace in version specifiers then joins the ability to omit the parentheses as a tooling UI decision that doesn't apply to the interchange standards.
> 
> Remember, the metadata PEPs are about specifying the *normalised* forms that are exchanged between automated tools. User facing tools are free to be more liberal in what they accept and handle the normalisation on their users' behalf
> 
> 

Are we planning on putting these someplace where we can't unambiguously parse
them? AFAIK in both the key:value form and the JSON form of the metadata are
perfectly capable (and it is in fact no different processing wise) of handling
them. AFAICT we're never going to rely on adhoc parsing here, at least we
shouldn't, so we don't need any help from the specifier in discerning between
two different ones.

Even if this is for the interchange format there is value in having it
consistent both for the benefit of the humans reading the interchange format
and for the benefit of the tooling so that they don't have to maintain two
different code paths to parse these.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140519/30718b4a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140519/30718b4a/attachment.sig>