On 22 December 2014 at 20:33, Donald Stufft wrote:

It’s true that pip doesn’t install pre-releases by default (assuming there is any final releases available), but that doesn’t actually solve the underlying problem - it just masks it. When people put ``foo<8`` in their install_requires they generally do not expect to get ``8.0.dev0``, and in my opinion, they shouldn’t get ``8.0.dev0`` even if someone uses —pre.

I see the point, but when *should* they get 8.0.dev0? It seems to me that "=8.0" (with --pre) is the correct answer. So <8.0 means 7.9 and earlier, >8.0 means 8.1 and later, =8.0 means 8.0 and any dev, pre, post and local releases. Essentially, any version X.Y.Z lumped together with all of its pre, post, local and dev versions, (mathematically a version is an equivalence class of all these) and otherwise ordering is a pretty straightforward ordering as if the version were a tuple (X, Y, Z). That's what my intuition says - are there any other ways that PEP 440 doesn't work like this?. Paul

* The new behavior maintains consistency between < and >, so that specifiers that “look” the same act the same, maintaining consistency between them. * I think that having the > and < behavior vary is a *worse* confusion, and I believe that the behavior of < is far better than previous.

I'm not following the old inconsistencies you're referring to. Maybe you can explain those, or reference this in the PEP. But in any case, the argument isn't over whether PEP440 is better than the old implementation, in total.

If I say I want foo > 2013, I expect anything in the 2014.*.* series. I don't expect 2013.*.* The same works for > 1.7

I wouldn't necessarily expect that, unless the PEP laid down these conceptual assumptions. maybe it's in there, I'm just not seeing it?

On Dec 23, 2014, at 1:23 AM, Marcus Smith wrote:

In particular, <, >, ~=, and, when using a .*, the != and == use the number of dots in the given specifier to indicate the precision of the specifier.

the PEP text is pretty clear on the precision concept for ~= and when using ".*", but not so much for < and <. how about an example right there in that section that mentions the "!= V.*"

We can certainly clarify the PEP test to make it easier to understand. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On 24 Dec 2014 05:27, "Marcus Smith" wrote:

just post edit suggestions here?

https://bitbucket.org/pypa/pypi-metadata-formats is not up to date

anymore

some other location?

It *should* be being kept in sync with the published versions, but Donald and I have just been working directly in the main PEP repo recently. Hence my suggestion of moving it to GitHub - it's more likely to be kept up to date there, and, unlike the master PEP repo, I'm happy to host the working drafts and issue tracker for the metadata PEPs wherever folks find them most convenient to work with. Cheers, Nick.

On Tue, Dec 23, 2014 at 1:01 AM, Donald Stufft wrote:

...

...

On Dec 23, 2014, at 1:23 AM, Marcus Smith wrote:

...

In particular, <, >, ~=, and, when using a .*, the != and == use the

number of dots in the given specifier to indicate the precision of the specifier.

...

...

the PEP text is pretty clear on the precision concept for ~= and when

using ".*", but not so much for < and <.

...

how about an example right there in that section that mentions the "!= V.*"

We can certainly clarify the PEP test to make it easier to understand.

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

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

On 25 Dec 2014 03:25, "Marcus Smith" wrote:

...

It *should* be being kept in sync with the published versions, but

...

Hence my suggestion of moving it to GitHub - it's more likely to be kept

up to date there, and, unlike the master PEP repo, I'm happy to host the working drafts and issue tracker for the metadata PEPs wherever folks find

Donald and I have just been working directly in the main PEP repo recently. them most convenient to work with.

I'd suggest pypa/peps on github (i.e. a more general name than

pypi-metadata-formats)

and ideally change the name of the pep src file after it has a pep number. (i.e. from versioning.rst to pep0440.rst) also, maybe isolate the named drafts (with no number) in a "drafts" folder.

Perhaps a "published" subfolder for snapshots of the released versions? The reason I went with the named drafts (rather than numbered) is because full spec revisions will get a new PEP number, but I figured it would be desirable to have a full version history under source control (rather than having to chase it across multiple files). Cheers, Nick.

So, if PyPI has foo-1.7 and foo-1.7.1, does ">1.7" just fail to find anything installable?

On 22 December 2014 at 20:44, Marcus Smith wrote:

it would fail. you'd need ">1.7.0"

On Mon, Dec 22, 2014 at 12:36 PM, James Bennett wrote:

...

So, if PyPI has foo-1.7 and foo-1.7.1, does ">1.7" just fail to find anything installable?

I think the thing I'd missed, which makes this behaviour more understandable (for me) is that you wouldn't usually get that in reality. Projects tend to use a fixed number of digits in the version number, so it'd likely be 1.7.0 and 1.7.1, and you'd be writing

1.7.0.

Thinking of ">1.7" as "greater than the 1.7 series" sort of helps me as well... Paul

On 23 Dec 2014, at 18:43, Paul Moore wrote:

On 22 December 2014 at 20:44, Marcus Smith wrote:

...

it would fail. you'd need ">1.7.0"

On Mon, Dec 22, 2014 at 12:36 PM, James Bennett wrote:

...

So, if PyPI has foo-1.7 and foo-1.7.1, does ">1.7" just fail to find anything installable?

I think the thing I'd missed, which makes this behaviour more understandable (for me) is that you wouldn't usually get that in reality. Projects tend to use a fixed number of digits in the version number, so it'd likely be 1.7.0 and 1.7.1, and you'd be writing

...

1.7.0.

For what it’s worth I usually skip a trailing .0 in my versions since it does not add any extra information. So my packages tend to do 1.6 1.6.1 1.6.2 1.7 1.7.1 etc. etc. Wichert.

On Fri, Dec 26, 2014 at 4:53 PM, Marcus Smith wrote:

...

Thinking of ">1.7" as "greater than the 1.7 series" sort of helps me as well...

the problem with thinking of it this way is that you naturally want to extend the concept to >=, but it doesn't work. If the concept were consistent, 1.7.dev1 would satisfy >=1.7, but it doesn't.

I'm pretty sure it's consistent. For example, "1.7.2" doesn't satisfy ">1.7", but it satisfies ">=1.7" (e.g. because it's "part of the series"). I believe the inconsistency you're mentioning doesn't have anything to do with the comparison operator. It's that pre-releases like "dev1" are special cases and governed by different rules. For example, from the "Handling of pre-releases" section, "Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release." And then it goes on. --Chris

for >=, the concept seems to be zero-padding. for >, the concept is the series wildcard idea.

this inconsistency concerns me, and makes it hard to edit the PEP to be more understandable like I would have wanted.

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

On Sat, Dec 27, 2014 at 2:13 AM, Marcus Smith wrote:

...

...

the problem with thinking of it this way is that you naturally want to extend the concept to >=, but it doesn't work. If the concept were consistent, 1.7.dev1 would satisfy >=1.7, but it doesn't.

I'm pretty sure it's consistent. For example, "1.7.2" doesn't satisfy ">1.7", but it satisfies ">=1.7" (e.g. because it's "part of the series").

I believe the inconsistency you're mentioning doesn't have anything to do with the comparison operator. It's that pre-releases like "dev1" are special cases and governed by different rules. [...] are implicitly excluded

but look at this (using setuptools 8)

...

...

...

'1.7.dev1' in pkg_resources.Requirement.parse('foo>=1.7') False '1.7.dev1' in pkg_resources.Requirement.parse('foo<=1.7') True

I believe the first example is a consequence of the following two excerpts from the PEP: (1) From the "Developmental releases" section: "Developmental releases are ordered by their numerical component, **immediately before the corresponding release** [my emphasis]...." (2) And from the "Inclusive ordered comparison" section: "An inclusive ordered comparison clause ... will match any version where the comparison is correct based on the relative position of the candidate version and the specified version given the consistent ordering defined by the standard Version scheme. ... As with version matching, the release segment is zero padded as necessary to ensure the release segments are compared with the same length." Since "1.7.dev1" is before its corresponding release "1.7" in the ordering, "1.7.dev1" does not satisfy "foo>=1.7". Similarly, "1.7.dev1" satisfies "foo<=1.7" since "1.7.dev1" precedes "1.7" in the ordering. In both cases (by (2) above), you are supposed to compare the candidate version "1.7.dev1" with the specified version "1.7". --Chris

Only the exclusive ordering section speaks of the "!= V.*" bit. The inclusive section just talks of zero padding and relative ordering.

The packaging implementation that underlies all this seems to bear this out as well:

inclusive: https://github.com/pypa/packaging/blob/master/packaging/specifiers.py#L453 exclusive: https://github.com/pypa/packaging/blob/master/packaging/specifiers.py#L461

Yes but thanks to Marc it now provides a clear message as to why. (Sent from my mobile) On Dec 23, 2014 11:22 AM, "James Bennett" wrote:

So, if PyPI has foo-1.7 and foo-1.7.1, does ">1.7" just fail to find anything installable?

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

On Mon, Dec 22, 2014 at 1:03 PM, Marcus Smith wrote:

This makes sense if you view "1.7" as encompassing all of the releases

...

1.7.0, 1.7.1, 1.7.2, etc. (and their variants). It's a bit like the "significant digits" of a number. [1] You want the release to be bigger than all releases of that type.

but is this really the underlying concept? Does the PEP explain this as a justification? Where?

I think so. I just read that part of the PEP. In the section "Exclusive ordered comparison," it says, "the comparison operators are < and > and the clause MUST be effectively interpreted as implying the prefix based version exclusion clause != V.* ." The key here is the reference to "prefix based" version exclusion (as opposed to "strict" version matching). If I understand correctly, this says that when "1.7.2" should be compared with "1.7" for equality, it should be compared with "1.7.*" as opposed to "1.7.0". This is described in the "Version matching" section. The prefix-based ".*" notation encapsulates what I said above about how "1.7" can be viewed as encompassing all of the releases 1.7.0, 1.7.1, etc. --Chris

On Mon, Dec 22, 2014 at 2:38 PM, Marcus Smith wrote:

there's a big difference between stating the concept directly/simply in the PEP vs readers/users having to reverse engineer it from "prefix based version exclusion clause != V.* ."

If this is what it's about, users need to be clearly informed (in the pip and PyPUG docs) that "1.7" effectively means "1.7.*" in specifiers.

FWIW, I agree the wording isn't very easy to follow (it reads more like a technical standard rather than something to educate). You have to unwind the logic from a few sections. By the way, note that "1.7" doesn't *always* mean "1.7.*" (in fact, it usually doesn't since the default is the "strict" form). From the "Version Matching" section: "By default, the version matching operator is based on a strict equality comparison: the specified version must be exactly the same as the requested version. The only substitution performed is the zero padding of the release segment to ensure the release segments are compared with the same length. "Whether or not strict version matching is appropriate depends on the specific use case for the version specifier. Automated tools SHOULD at least issue warnings and MAY reject them entirely when strict version matches are used inappropriately. "Prefix matching may be requested instead of strict comparison, by appending a trailing .* to the version identifier in the version matching clause." --Chris

On Mon, Dec 22, 2014 at 1:31 PM, Chris Jerdonek wrote:

...

On Mon, Dec 22, 2014 at 1:03 PM, Marcus Smith wrote:

...

This makes sense if you view "1.7" as encompassing all of the releases

...

1.7.0, 1.7.1, 1.7.2, etc. (and their variants). It's a bit like the "significant digits" of a number. [1] You want the release to be bigger than all releases of that type.

but is this really the underlying concept? Does the PEP explain this as a justification? Where?

I think so. I just read that part of the PEP.

In the section "Exclusive ordered comparison," it says, "the comparison operators are < and > and the clause MUST be effectively interpreted as implying the prefix based version exclusion clause != V.* ."

The key here is the reference to "prefix based" version exclusion (as opposed to "strict" version matching). If I understand correctly, this says that when "1.7.2" should be compared with "1.7" for equality, it should be compared with "1.7.*" as opposed to "1.7.0". This is described in the "Version matching" section.

The prefix-based ".*" notation encapsulates what I said above about how "1.7" can be viewed as encompassing all of the releases 1.7.0, 1.7.1, etc.

--Chris