PEP440: foo-X.Y.Z does not satisfy "foo>X.Y"?
In PEP440, foo-X.Y.Z does not satisfy the specifier "foo>X.Y" (although it satisfies "foo>=X.Y")
for example, foo-1.7.2 will not satisfy "foo>1.7", but it will satisfy "foo>=1.7"
for '>' and '<', PEP440 states that they are "interpreted as implying the prefix based version exclusion clause != V.*"
the rationale from Donald for this is explained here: https://bitbucket.org/pypa/setuptools/issue/301/101-in-requirementparse-foo-...
in brief, this was done to avoid pre-releases (i.e. something like "foo-1.7a1") satisfying "foo<1.7".
It seems to me we've just traded one confusion for another, and this seems worse (to me at least, although I'm trying to let it sink in)
1.7.2 is greater than 1.7, and the specifiers should honor that. It's hard to accept otherwise.
Yes, it's true in the past, when people would get a pre-release installed (for example 1.7a1), when they really wanted something in the 1.6.X series, that was also confusing. But now that pip now excludes pre-releases by default, it seems that confusion is mostly solved practically speaking, so why solve it (and create a new confusion)?
Marcus
On 22 December 2014 at 20:20, Marcus Smith qwcode@gmail.com wrote:
In PEP440, foo-X.Y.Z does not satisfy the specifier "foo>X.Y" (although it satisfies "foo>=X.Y")
for example, foo-1.7.2 will not satisfy "foo>1.7", but it will satisfy "foo>=1.7"
for '>' and '<', PEP440 states that they are "interpreted as implying the prefix based version exclusion clause != V.*"
the rationale from Donald for this is explained here: https://bitbucket.org/pypa/setuptools/issue/301/101-in-requirementparse-foo-...
in brief, this was done to avoid pre-releases (i.e. something like "foo-1.7a1") satisfying "foo<1.7".
It seems to me we've just traded one confusion for another, and this seems worse (to me at least, although I'm trying to let it sink in)
1.7.2 is greater than 1.7, and the specifiers should honor that. It's hard to accept otherwise.
Yes, it's true in the past, when people would get a pre-release installed (for example 1.7a1), when they really wanted something in the 1.6.X series, that was also confusing. But now that pip now excludes pre-releases by default, it seems that confusion is mostly solved practically speaking, so why solve it (and create a new confusion)?
Hmm, yes, I'd have to say that sounds like a recipe for bug reports.
+1 for updating PEP 440 (and pip) so that 1.7.2 is > 1.7. Maybe add a note to PEP 440 that installers SHOULD exclude pre-releases by default (with a note mentioning the 1.7a1 < 1.7 case as the justification).
Paul
On Dec 22, 2014, at 3:20 PM, Marcus Smith qwcode@gmail.com wrote:
In PEP440, foo-X.Y.Z does not satisfy the specifier "foo>X.Y" (although it satisfies "foo>=X.Y")
for example, foo-1.7.2 will not satisfy "foo>1.7", but it will satisfy "foo>=1.7"
for '>' and '<', PEP440 states that they are "interpreted as implying the prefix based version exclusion clause != V.*"
the rationale from Donald for this is explained here: https://bitbucket.org/pypa/setuptools/issue/301/101-in-requirementparse-foo-... https://bitbucket.org/pypa/setuptools/issue/301/101-in-requirementparse-foo-10-results
in brief, this was done to avoid pre-releases (i.e. something like "foo-1.7a1") satisfying "foo<1.7".
It seems to me we've just traded one confusion for another, and this seems worse (to me at least, although I'm trying to let it sink in)
1.7.2 is greater than 1.7, and the specifiers should honor that. It's hard to accept otherwise.
Yes, it's true in the past, when people would get a pre-release installed (for example 1.7a1), when they really wanted something in the 1.6.X series, that was also confusing. But now that pip now excludes pre-releases by default, it seems that confusion is mostly solved practically speaking, so why solve it (and create a new confusion)?
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.
In a way, we have replaced one confusion for another, although I do not believe it to be that bad and I believe that the current situation is better because:
* In my searches of github and my experience, use of the > instead of >= is fairly limited, meanwhile use of < to mean how it’s interpreted now is far more common. * 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.
In particular, <, >, ~=, and, when using a .*, the != and == use the number of dots in the given specifier to indicate the precision of the specifier.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 22 December 2014 at 20:33, Donald Stufft donald@stufft.io 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
On Dec 22, 2014, at 3:43 PM, Paul Moore p.f.moore@gmail.com wrote:
On 22 December 2014 at 20:33, Donald Stufft donald@stufft.io 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?.
You won’t get 8.0.dev1 with a == operation. You would get it with <=8 and of course you’d get it with a >7 if 8.0.dev1 was the newest available.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
- 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.
The other way in which this makes a whole lot more sense is when considering projects that use dates as versions. Let's take for example projects that have a released versions like
2013.08.10 2013.10.30 2013.12.03 2014.02.16 2014.09.23
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
On Mon, Dec 22, 2014 at 3:12 PM, Marcus Smith qwcode@gmail.com wrote:
- 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.
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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.*"
On Dec 23, 2014, at 1:23 AM, Marcus Smith qwcode@gmail.com 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
just post edit suggestions here?
https://bitbucket.org/pypa/pypi-metadata-formats is not up to date anymore
some other location?
On Tue, Dec 23, 2014 at 1:01 AM, Donald Stufft donald@stufft.io wrote:
On Dec 23, 2014, at 1:23 AM, Marcus Smith qwcode@gmail.com 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" qwcode@gmail.com 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 donald@stufft.io wrote:
On Dec 23, 2014, at 1:23 AM, Marcus Smith qwcode@gmail.com 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
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.
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.
On 25 Dec 2014 03:25, "Marcus Smith" qwcode@gmail.com wrote:
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.
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.
On Mon, Dec 22, 2014 at 12:20 PM, Marcus Smith qwcode@gmail.com wrote:
In PEP440, foo-X.Y.Z does not satisfy the specifier "foo>X.Y" (although it satisfies "foo>=X.Y")
for example, foo-1.7.2 will not satisfy "foo>1.7", but it will satisfy "foo>=1.7"
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.
--Chris
[1] http://en.wikipedia.org/wiki/Significant_figures
for '>' and '<', PEP440 states that they are "interpreted as implying the prefix based version exclusion clause != V.*"
the rationale from Donald for this is explained here: https://bitbucket.org/pypa/setuptools/issue/301/101-in-requirementparse-foo-...
in brief, this was done to avoid pre-releases (i.e. something like "foo-1.7a1") satisfying "foo<1.7".
It seems to me we've just traded one confusion for another, and this seems worse (to me at least, although I'm trying to let it sink in)
1.7.2 is greater than 1.7, and the specifiers should honor that. It's hard to accept otherwise.
Yes, it's true in the past, when people would get a pre-release installed (for example 1.7a1), when they really wanted something in the 1.6.X series, that was also confusing. But now that pip now excludes pre-releases by default, it seems that confusion is mostly solved practically speaking, so why solve it (and create a new confusion)?
Marcus
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
So, if PyPI has foo-1.7 and foo-1.7.1, does ">1.7" just fail to find anything installable?
it would fail. you'd need ">1.7.0"
On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernostrum@gmail.com wrote:
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 qwcode@gmail.com wrote:
it would fail. you'd need ">1.7.0"
On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernostrum@gmail.com 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
It also provides consistency with date-based versions. And versions aren't decimals so thinking of them like that is not exactly useful. On Dec 23, 2014 11:43 AM, "Paul Moore" p.f.moore@gmail.com wrote:
On 22 December 2014 at 20:44, Marcus Smith qwcode@gmail.com wrote:
it would fail. you'd need ">1.7.0"
On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernostrum@gmail.com 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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 23 Dec 2014, at 18:43, Paul Moore p.f.moore@gmail.com wrote:
On 22 December 2014 at 20:44, Marcus Smith qwcode@gmail.com wrote:
it would fail. you'd need ">1.7.0"
On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernostrum@gmail.com 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.
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. 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.
On Fri, Dec 26, 2014 at 4:53 PM, Marcus Smith qwcode@gmail.com 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
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
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
On Sat, Dec 27, 2014 at 2:13 AM, Marcus Smith qwcode@gmail.com 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
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 [...] In both cases (by (2) above), you
are supposed to compare the
candidate version "1.7.dev1" with the specified version "1.7".
yes, I agree with you. : ) my 2 examples weren't meant to exemplify the inconsistency I was referring to. they were intended to be response to you quoting the bit about "implicitly excluded" Because the 2nd example was True, they're not implicitly excluded.
For fear that my current point is lost now (since it's changed from the original title), I'm going to start a new thread that sums it up real brief...
Marcus
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" ubernostrum@gmail.com 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
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?
On Mon, Dec 22, 2014 at 1:03 PM, Marcus Smith qwcode@gmail.com 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
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.
On Mon, Dec 22, 2014 at 1:31 PM, Chris Jerdonek chris.jerdonek@gmail.com wrote:
On Mon, Dec 22, 2014 at 1:03 PM, Marcus Smith qwcode@gmail.com 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 qwcode@gmail.com 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 chris.jerdonek@gmail.com wrote:
On Mon, Dec 22, 2014 at 1:03 PM, Marcus Smith qwcode@gmail.com 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
participants (8)
-
Chris Jerdonek -
Donald Stufft -
Ian Cordasco -
James Bennett -
Marcus Smith -
Nick Coghlan -
Paul Moore -
Wichert Akkerman