I'm starting a new thread to state cleanly what my current question/concern is...
per PEP440 as I understand it: - for ">1.7", "1.7" means roughly the "1.7 series" or "1.7*" - for ">=1.7", "1.7" means literally "1.7" (with zero-padding as needed)
While I understand the motivation for the "series" conception of 1.7 to deal with prereleases, the resulting inconsistency in meaning for "1.7" is what concerns me. It's odd . Can someone make it not seem odd for "1.7 to change meanings just because you switch between >= and >?
And for anyone who wants to say that "1.7" also means the "1.7 series" for
=, note that 1.7 prereleases do not satisfy >=1.7
Would a solution be to make >= also use the series concept?, i.e. make pre-releases satisfy >=1.7
Marcus
On Dec 27, 2014, at 8:35 PM, Marcus Smith qwcode@gmail.com wrote:
I'm starting a new thread to state cleanly what my current question/concern is...
per PEP440 as I understand it:
- for ">1.7", "1.7" means roughly the "1.7 series" or "1.7*"
- for ">=1.7", "1.7" means literally "1.7" (with zero-padding as needed)
While I understand the motivation for the "series" conception of 1.7 to deal with prereleases, the resulting inconsistency in meaning for "1.7" is what concerns me. It's odd . Can someone make it not seem odd for "1.7 to change meanings just because you switch between >= and >?
And for anyone who wants to say that "1.7" also means the "1.7 series" for >=, note that 1.7 prereleases do not satisfy >=1.7
Would a solution be to make >= also use the series concept?, i.e. make pre-releases satisfy >=1.7
The equality operator pads zeros, >= has the equality operator as part of it.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Dec 27, 2014, at 8:57 PM, Marcus Smith qwcode@gmail.com wrote:
The equality operator pads zeros, >= has the equality operator as part of it.
right, but that's not really an answer. Does the conceptual inconsistency phase you at all?
In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare > and any alternative I can come up with has worse behavior for operators which get much more use.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare > and any alternative I can come up with has worse behavior for operators which get much more use.
what about making >=,<= also use the series concept? where does that go wrong?
On Dec 27, 2014, at 9:10 PM, Marcus Smith qwcode@gmail.com wrote:
In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare > and any alternative I can come up with has worse behavior for operators which get much more use.
what about making >=,<= also use the series concept? where does that go wrong?
To be clear, you’re talking about doing something like:
1.7 is >1.7 AND !=1.7.* which would correlate to >1.7 OR ==1.7.*?
Honestly, the thing that I dislike about that is it takes a behavior which is less intuitive (I do agree that the behavior of > is less intuitive) and applies to globally. I don't think people would expect >=1.7 to match 1.7.dev0 and given that I don't think people would expect >=1.7.0 to _not_match 1.7.dev0.
I totally agree that the behavior of > isn't the greatest, I don't think the solution to that problem is to globally apply that particular wart. The only *reasonable* solutions I can think of are:
1. Make < and > both act as simple comparison operators, and have >1.7 and
1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to be
<1.7 and <1.7.0.
2. Make < and > both act as "exclusive comparison operators", and which is the current behavior.
3. Make < and > both act as simple comparison operators, but include a special case that < does not ever match pre-releases of the version mentioned in the specifier. So <3 would not match a pre-released like 3.dev0, and <3.1 would not match a pre-release like 3.1.dev0 but would match a pre-release like 3.0.dev0.
It may be that the correct solution is to just treat pre-releases as special and just switch to 3.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Dec 27, 2014, at 9:26 PM, Donald Stufft donald@stufft.io wrote:
On Dec 27, 2014, at 9:10 PM, Marcus Smith <qwcode@gmail.com mailto:qwcode@gmail.com> wrote:
In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare > and any alternative I can come up with has worse behavior for operators which get much more use.
what about making >=,<= also use the series concept? where does that go wrong?
To be clear, you’re talking about doing something like:
1.7 is >1.7 AND !=1.7.* which would correlate to >1.7 OR ==1.7.*?
Honestly, the thing that I dislike about that is it takes a behavior which is less intuitive (I do agree that the behavior of > is less intuitive) and applies to globally. I don't think people would expect >=1.7 to match 1.7.dev0 and given that I don't think people would expect >=1.7.0 to _not_match 1.7.dev0.
I totally agree that the behavior of > isn't the greatest, I don't think the solution to that problem is to globally apply that particular wart. The only *reasonable* solutions I can think of are:
Make < and > both act as simple comparison operators, and have >1.7 and
1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to be
<1.7 and <1.7.0.
Make < and > both act as "exclusive comparison operators", and which is the current behavior.
Make < and > both act as simple comparison operators, but include a special case that < does not ever match pre-releases of the version mentioned in the specifier. So <3 would not match a pre-released like 3.dev0, and <3.1 would not match a pre-release like 3.1.dev0 but would match a pre-release like 3.0.dev0.
It may be that the correct solution is to just treat pre-releases as special and just switch to 3.
After thinking about this some more, I made a PR that adjusts the packaging library so that is has semantics which might be better overall than what is currently in PEP 440. This PR is at https://github.com/pypa/packaging/pull/25 if someone wants to play with it at all, but the highlights are:
* 1.7.1 matches >1.7 (previously it did not) * 1.7.post1 does not match >1.7 (previously it did not) * 1.7.post1 matches >1.7.post0 (previously it did) * 3.dev0 does not match <3.0 (previously it did) * 3.0.dev0 does not match <3.0 (previously it did not) * 3.0.dev0 matches <3.0rc1 (previously it did)
Instead of having >V and <V impliy !=V.*, this means that:
1. A <V does not match a pre-release of V unless V is itself a pre-release. 2. A >V does not match a post-release of V unless V is itself a post-release. 3. A >V does not match a V+local.version.
Implicitly these three rules are also true, but they are true because of the ordered nature of the versions and the mathemtical meaning of > and < rather than any rule mentioned in the PEP:
4. A <V does not match a post-release of V unless V is itself a post-release. 5. A >V does not match a pre-release of V unless V is itself a pre-release. 6. A <V does not match a V+local.version.
If you check out my branch, you can play around with the specifier rules as I've implemented them now by just doing:
>>> from packaging.specifiers import SpecifierSet >>> SpecifierSet(">1.7").contains("1.7.1", prereleases=True) True >>> SpecifierSet(">1.7").contains("1.7.post1", prereleases=True) False >>> SpecifierSet(">1.7.post0").contains("1.7.post1", prereleases=True) True >>> SpecifierSet(">1.7").contains("1.7+thing.1", prereleases=True) False >>> SpecifierSet("<3.0.0").contains("3.0.dev0", prereleases=True) False >>> SpecifierSet("<3").contains("3.0.dev0", prereleases=True) False >>> SpecifierSet("<3rc1").contains("3.0.dev0", prereleases=True) True
Does this better match your expectations? I think I might like these rules better as they handle zero padding similarly to ==, !=, >=, and <= (sans when == and != have a .*) which means that a rule like <3.0 won't accept 3.dev0 even though the current PEP means that it does. I think it also follows along better with what people expect both for > and for <.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 28 Dec 2014 17:12, "Donald Stufft" donald@stufft.io wrote:
On Dec 27, 2014, at 9:26 PM, Donald Stufft donald@stufft.io wrote:
On Dec 27, 2014, at 9:10 PM, Marcus Smith qwcode@gmail.com wrote:
In gives me a minor bit of pause. However any alternative that I can
come up
with bothers me more, especially since I don't believe many people
actually
even *use* a bare > and any alternative I can come up with has worse
behavior
for operators which get much more use.
what about making >=,<= also use the series concept? where does that go
wrong?
To be clear, you’re talking about doing something like:
1.7 is >1.7 AND !=1.7.* which would correlate to >1.7 OR ==1.7.*?
Honestly, the thing that I dislike about that is it takes a behavior
which is
less intuitive (I do agree that the behavior of > is less intuitive) and applies to globally. I don't think people would expect >=1.7 to match
1.7.dev0
and given that I don't think people would expect >=1.7.0 to _not_match 1.7.dev0.
I totally agree that the behavior of > isn't the greatest, I don't think
the
solution to that problem is to globally apply that particular wart. The
only
*reasonable* solutions I can think of are:
- Make < and > both act as simple comparison operators, and have >1.7
and
1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to
be
<1.7 and <1.7.0.
- Make < and > both act as "exclusive comparison operators", and which
is
the current behavior.
- Make < and > both act as simple comparison operators, but include a
special
case that < does not ever match pre-releases of the version mentioned
in
the specifier. So <3 would not match a pre-released like 3.dev0, and
<3.1
would not match a pre-release like 3.1.dev0 but would match a
pre-release
like 3.0.dev0.
It may be that the correct solution is to just treat pre-releases as
special
and just switch to 3.
After thinking about this some more, I made a PR that adjusts the
packaging
library so that is has semantics which might be better overall than what
is
currently in PEP 440. This PR is at
https://github.com/pypa/packaging/pull/25
if someone wants to play with it at all, but the highlights are:
- 1.7.1 matches >1.7 (previously it did not)
This sounds like a straight up bug fix in the packaging module to me - the PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
Hence this sentence in the description of the release segment under the "Final releases" heading: "When comparing release segments with different numbers of components, the shorter segment is padded out with additional zeros as necessary."
The zero padding does get called out again explicitly in the section on version matching, but that's in the context of explaining why "== 1.7" will match "1.7.0" and vice-versa, even though version matching is otherwise strict.
- 1.7.post1 does not match >1.7 (previously it did not)
- 1.7.post1 matches >1.7.post0 (previously it did)
- 3.dev0 does not match <3.0 (previously it did)
This is another bug fix - avoiding that match is one of the key reasons for the wildcard exclusion in the definition of the exclusive comparison operators.
Given the next bullet point, it sounds like this may have been another symptom of incorrectly limiting the release segment zero padding to version matching operations.
- 3.0.dev0 does not match <3.0 (previously it did not)
- 3.0.dev0 matches <3.0rc1 (previously it did)
Instead of having >V and <V impliy !=V.*, this means that:
- A <V does not match a pre-release of V unless V is itself a
pre-release.
- A >V does not match a post-release of V unless V is itself a
post-release.
- A >V does not match a V+local.version.
Please don't make the change more complicated than it needs to be - there's just a bug in the packaging implementation of the PEP semantics. Zero padding of the release segment should be applied to all operations, and that currently isn't happening.
Regards, Nick.
- 1.7.1 matches >1.7 (previously it did not)
This sounds like a straight up bug fix in the packaging module to me - the PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
OK. to be clear, I guess you really didn't follow the previous thread? I specifically raised the concern over 1.7.1 not matching >1.7 (in the current implementation), but most people were arguing it was a logical interpretation of PEP440.
Marcus
On Sun, Dec 28, 2014 at 1:20 PM, Marcus Smith qwcode@gmail.com wrote:
- 1.7.1 matches >1.7 (previously it did not)
This sounds like a straight up bug fix in the packaging module to me - the PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
OK. to be clear, I guess you really didn't follow the previous thread? I specifically raised the concern over 1.7.1 not matching >1.7 (in the current implementation), but most people were arguing it was a logical interpretation of PEP440.
I think Nick's e-mail clarifies it for me.
In my e-mail, I was reconciling the current behavior with the current wording of the PEP, which says, "Exclusive ordered comparisons are similar to inclusive ordered comparisons, except that the comparison operators are < and > and the clause MUST be effectively interpreted as implying the prefix based version exclusion clause != V.*."
I now see that the wording is a bit ambiguous (or at least that I was misinterpreting it). I interpreted it to mean that prefix-based version exclusion should be used *instead* of zero-padding, whereas with Nick's e-mail, I see that the meaning is that prefix-based exclusion should be used *after* applying zero padding.
The clarified interpretation also addresses an asymmetry of the previously mentioned (and now apparently incorrect) "series" interpretation, which I'm not sure was mentioned before. Namely, 1.7.2 satisfies ">=1.7" but does not satisfy "<=1.7". With the series interpretation, the latter wouldn't be consistent (since 1.7.2 is part of the series under that interpretation).
--Chris
Marcus
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I personally think that 1.7.1 matching >1.7 muddies some applications of it being used with date-based versions with this pep also supports. This (as best I can tell) means that now 2014.09.31 will match > 2014.09 which seems like a rather terrible idea. No one expects a date to be padded with 0s. I'm also fully against special casing date-based versions because the whole point of 440 was to make versioning consistent and reliable and I wholeheartedly want that.
On Sun, Dec 28, 2014 at 1:43 PM, Chris Jerdonek chris.jerdonek@gmail.com wrote:
On Sun, Dec 28, 2014 at 1:20 PM, Marcus Smith qwcode@gmail.com wrote:
- 1.7.1 matches >1.7 (previously it did not)
This sounds like a straight up bug fix in the packaging module to me - the PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
OK. to be clear, I guess you really didn't follow the previous thread? I specifically raised the concern over 1.7.1 not matching >1.7 (in the current implementation), but most people were arguing it was a logical interpretation of PEP440.
I think Nick's e-mail clarifies it for me.
In my e-mail, I was reconciling the current behavior with the current wording of the PEP, which says, "Exclusive ordered comparisons are similar to inclusive ordered comparisons, except that the comparison operators are < and > and the clause MUST be effectively interpreted as implying the prefix based version exclusion clause != V.*."
I now see that the wording is a bit ambiguous (or at least that I was misinterpreting it). I interpreted it to mean that prefix-based version exclusion should be used *instead* of zero-padding, whereas with Nick's e-mail, I see that the meaning is that prefix-based exclusion should be used *after* applying zero padding.
The clarified interpretation also addresses an asymmetry of the previously mentioned (and now apparently incorrect) "series" interpretation, which I'm not sure was mentioned before. Namely, 1.7.2 satisfies ">=1.7" but does not satisfy "<=1.7". With the series interpretation, the latter wouldn't be consistent (since 1.7.2 is part of the series under that interpretation).
--Chris
Marcus
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Sunday, December 28, 2014, Ian Cordasco graffatcolmingov@gmail.com wrote:
I personally think that 1.7.1 matching >1.7 muddies some applications of it being used with date-based versions with this pep also supports. This (as best I can tell) means that now 2014.09.31 will match > 2014.09 which seems like a rather terrible idea. No one expects a date to be padded with 0s. I'm also fully against special casing date-based versions because the whole point of 440 was to make versioning consistent and reliable and I wholeheartedly want that.
To add another wrinkle, do you think 2014.09.01 should or shouldn't match "<=2014.09"?
This is an example of the case I mentioned at the end of my previous email.
--Chris
On Sun, Dec 28, 2014 at 1:43 PM, Chris Jerdonek <chris.jerdonek@gmail.com javascript:;> wrote:
On Sun, Dec 28, 2014 at 1:20 PM, Marcus Smith <qwcode@gmail.com
javascript:;> wrote:
- 1.7.1 matches >1.7 (previously it did not)
This sounds like a straight up bug fix in the packaging module to me -
the
PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
OK. to be clear, I guess you really didn't follow the previous thread? I specifically raised the concern over 1.7.1 not matching >1.7 (in the current implementation), but most people were arguing it was a logical interpretation of PEP440.
I think Nick's e-mail clarifies it for me.
In my e-mail, I was reconciling the current behavior with the current wording of the PEP, which says, "Exclusive ordered comparisons are similar to inclusive ordered comparisons, except that the comparison operators are < and > and the clause MUST be effectively interpreted as implying the prefix based version exclusion clause != V.*."
I now see that the wording is a bit ambiguous (or at least that I was misinterpreting it). I interpreted it to mean that prefix-based version exclusion should be used *instead* of zero-padding, whereas with Nick's e-mail, I see that the meaning is that prefix-based exclusion should be used *after* applying zero padding.
The clarified interpretation also addresses an asymmetry of the previously mentioned (and now apparently incorrect) "series" interpretation, which I'm not sure was mentioned before. Namely, 1.7.2 satisfies ">=1.7" but does not satisfy "<=1.7". With the series interpretation, the latter wouldn't be consistent (since 1.7.2 is part of the series under that interpretation).
--Chris
Marcus
Distutils-SIG maillist - Distutils-SIG@python.org javascript:; https://mail.python.org/mailman/listinfo/distutils-sig
Distutils-SIG maillist - Distutils-SIG@python.org javascript:; https://mail.python.org/mailman/listinfo/distutils-sig
On Dec 28, 2014, at 9:57 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On 28 Dec 2014 17:12, "Donald Stufft" <donald@stufft.io mailto:donald@stufft.io> wrote:
On Dec 27, 2014, at 9:26 PM, Donald Stufft <donald@stufft.io mailto:donald@stufft.io> wrote:
On Dec 27, 2014, at 9:10 PM, Marcus Smith <qwcode@gmail.com mailto:qwcode@gmail.com> wrote:
In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare > and any alternative I can come up with has worse behavior for operators which get much more use.
what about making >=,<= also use the series concept? where does that go wrong?
To be clear, you’re talking about doing something like:
1.7 is >1.7 AND !=1.7.* which would correlate to >1.7 OR ==1.7.*?
Honestly, the thing that I dislike about that is it takes a behavior which is less intuitive (I do agree that the behavior of > is less intuitive) and applies to globally. I don't think people would expect >=1.7 to match 1.7.dev0 and given that I don't think people would expect >=1.7.0 to _not_match 1.7.dev0.
I totally agree that the behavior of > isn't the greatest, I don't think the solution to that problem is to globally apply that particular wart. The only *reasonable* solutions I can think of are:
Make < and > both act as simple comparison operators, and have >1.7 and
1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to be
<1.7 and <1.7.0.
Make < and > both act as "exclusive comparison operators", and which is the current behavior.
Make < and > both act as simple comparison operators, but include a special case that < does not ever match pre-releases of the version mentioned in the specifier. So <3 would not match a pre-released like 3.dev0, and <3.1 would not match a pre-release like 3.1.dev0 but would match a pre-release like 3.0.dev0.
It may be that the correct solution is to just treat pre-releases as special and just switch to 3.
After thinking about this some more, I made a PR that adjusts the packaging library so that is has semantics which might be better overall than what is currently in PEP 440. This PR is at https://github.com/pypa/packaging/pull/25 https://github.com/pypa/packaging/pull/25 if someone wants to play with it at all, but the highlights are:
- 1.7.1 matches >1.7 (previously it did not)
This sounds like a straight up bug fix in the packaging module to me - the PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
Hence this sentence in the description of the release segment under the "Final releases" heading: "When comparing release segments with different numbers of components, the shorter segment is padded out with additional zeros as necessary."
The zero padding does get called out again explicitly in the section on version matching, but that's in the context of explaining why "== 1.7" will match "1.7.0" and vice-versa, even though version matching is otherwise strict.
- 1.7.post1 does not match >1.7 (previously it did not)
- 1.7.post1 matches >1.7.post0 (previously it did)
- 3.dev0 does not match <3.0 (previously it did)
This is another bug fix - avoiding that match is one of the key reasons for the wildcard exclusion in the definition of the exclusive comparison operators.
Given the next bullet point, it sounds like this may have been another symptom of incorrectly limiting the release segment zero padding to version matching operations.
- 3.0.dev0 does not match <3.0 (previously it did not)
- 3.0.dev0 matches <3.0rc1 (previously it did)
Instead of having >V and <V impliy !=V.*, this means that:
- A <V does not match a pre-release of V unless V is itself a pre-release.
- A >V does not match a post-release of V unless V is itself a post-release.
- A >V does not match a V+local.version.
Please don't make the change more complicated than it needs to be - there's just a bug in the packaging implementation of the PEP semantics. Zero padding of the release segment should be applied to all operations, and that currently isn't happening.
Regards, Nick.
The > and < operators are currently implemented exactly how they are defined in the PEP. If we want to change that, that's fine, but the packaging library is correct to the PEP currently.
The PEP says:
Exclusive ordered comparisons are similar to inclusive ordered comparisons, except that the comparison operators are < and > and the clause MUST be effectively interpreted as implying the prefix based version exclusion clause != V.* .
The exclusive ordered comparison > V MUST NOT match a post-release or maintenance release of the given version. Maintenance releases can be permitted by using the clause > V.0 , while both post releases and maintenance releases can be permitted by using the inclusive ordered comparison >= V.post1 .
The exclusive ordered comparison < V MUST NOT match a pre-release of the given version, even if acceptance of pre-releases is enabled as described in the section below.
Local version identifiers are NOT permitted in this version specifier.
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.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
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.
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.
On 29 December 2014 at 15:01, Nick Coghlan ncoghlan@gmail.com wrote:
Next steps:
- I'll update the currently published version of PEP 440 to include a note
regarding its provisional status
I just pushed this as https://hg.python.org/peps/rev/a532493ba99c
Cheers, Nick.
On Dec 29, 2014, at 12:01 AM, Nick Coghlan ncoghlan@gmail.com wrote:
- 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)
See: https://github.com/pypa/interoperability-peps/pull/3
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
how about just pypa/peps for the name?
On Sun, Dec 28, 2014 at 10:16 PM, Donald Stufft donald@stufft.io wrote:
On Dec 29, 2014, at 12:01 AM, Nick Coghlan ncoghlan@gmail.com wrote:
- 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)
See: https://github.com/pypa/interoperability-peps/pull/3
Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 29 December 2014 at 17:12, Marcus Smith qwcode@gmail.com wrote:
how about just pypa/peps for the name?
I would find the name clash with the main peps repo very annoying :)
Cheers, Nick.
On Dec 29, 2014, at 2:22 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On 29 December 2014 at 17:12, Marcus Smith <qwcode@gmail.com mailto:qwcode@gmail.com> wrote: how about just pypa/peps for the name?
I would find the name clash with the main peps repo very annoying :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com mailto:ncoghlan@gmail.com | Brisbane, Australia
lol, I have dstufft/peps already, and python/peps, what’s a third clash :V
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Mon, Dec 29, 2014 at 12:01 AM, Nick Coghlan ncoghlan@gmail.com wrote:
- 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.
Just to confirm, in each of the below is it true that the two comparisons are exactly equivalent (taking into account pre-release and post-release rules, etc)?
1) >V.N.* and >=V.N+1 2) <=V.N.* and <V.N+1
And these two should be even easier:
3) <V.* and <V 4) >=V.* and >=V
With the way the PEP is written, it's not completely obvious to me that these are true.
Thanks, --Chris
On Dec 29, 2014, at 2:09 PM, Chris Jerdonek chris.jerdonek@gmail.com wrote:
On Mon, Dec 29, 2014 at 12:01 AM, Nick Coghlan ncoghlan@gmail.com wrote:
- 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.
Just to confirm, in each of the below is it true that the two comparisons are exactly equivalent (taking into account pre-release and post-release rules, etc)?
- <=V.N.* and <V.N+1
And these two should be even easier:
- <V.* and <V
With the way the PEP is written, it's not completely obvious to me that these are true.
Thanks, --Chris
The .* operator is not currently allowed other than in == and != in PEP 440, that was just a suggestion of a possible future enhancement to make it easier to get the behavior that people likely want for date based releases. Currently with the suggested updates to PEP 440 they'd need to do something like >V,!=V.* to get that behavior.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 30 December 2014 at 05:09, Chris Jerdonek chris.jerdonek@gmail.com wrote:
On Mon, Dec 29, 2014 at 12:01 AM, Nick Coghlan ncoghlan@gmail.com wrote:
- 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.
Just to confirm, in each of the below is it true that the two comparisons are exactly equivalent (taking into account pre-release and post-release rules, etc)?
- <=V.N.* and <V.N+1
If you omit the trailing ".*" (which isn't part of PEP 440 in the context of ordered comparisons), then the following are equivalent in the currently published version of the PEP:
1) "> V.N" and ">= V.N+1" 2) "<= V.N" and "< V.N+1"
The current behaviour of those exclusive comparisons is the part that's both incompatible with the previous behaviour of setuptools/pkg_resources, and somewhat confusing (largely because the interaction between the zero padding and the negative prefix matching means that the trailing zero in the release segment effectively isn't implied when comparing against maintenance releases).
Donald's proposed adjustment at https://github.com/pypa/interoperability-peps/pull/3 (which I now agree with) changes them to be different: unlike ">= V.N+1", "> V.N" will once again allow "V.N.x" maintenance releases, as it did in setuptools/pkg_resources releases prior to 8.0.
The exclusive ordered comparison behaviour in the originally accepted version of the PEP can still be requested explicitly as "< V, != V.*" and "> V, != V.*" (where the latter has the virtue of failing noisily on older versions of pkg_resources, rather than silently referring to a different minimum version).
And these two should be even easier:
- <V.* and <V
With the way the PEP is written, it's not completely obvious to me that these are true.
In a hypothetical future version of the PEP that allowed the ".*" wildcard suffix for ordered comparisons, it would likely have the following semantics:
"< V.*" ==> "< V, != V.*" "> V.*" ==> "> V, != V.*" "<= V.*" ==> "<= V" ">= V.*" ==> ">= V"
However, it's not clear that such an addition would be worth it, given the updated definition of exclusive comparisons, and the availability of the more explicit spelling.
Cheers, Nick.
On Sat, Dec 27, 2014 at 7:35 PM, Marcus Smith qwcode@gmail.com wrote:
I'm starting a new thread to state cleanly what my current question/concern is...
per PEP440 as I understand it:
- for ">1.7", "1.7" means roughly the "1.7 series" or "1.7*"
You mean "1.7.*" right? Because 1.70 would satisfy >1.7
- for ">=1.7", "1.7" means literally "1.7" (with zero-padding as needed)
While I understand the motivation for the "series" conception of 1.7 to deal with prereleases, the resulting inconsistency in meaning for "1.7" is what concerns me. It's odd . Can someone make it not seem odd for "1.7 to change meanings just because you switch between >= and >?
And for anyone who wants to say that "1.7" also means the "1.7 series" for
=, note that 1.7 prereleases do not satisfy >=1.7
Would a solution be to make >= also use the series concept?, i.e. make pre-releases satisfy >=1.7
Marcus
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-
Chris Jerdonek -
Donald Stufft -
Ian Cordasco -
Marcus Smith -
Nick Coghlan