At 01:38 PM 6/11/2009 -0700, Trent Mick wrote:
- when I specify a dependency against a particular build_number of a
package, I don't care if that build_number happened to be a released version or a dev version
However, to specify that dependency you're going to need a way to represent the build number as part of a requirement string, at which point we're right back where we started.
- when I specify a dependency against a particular build_number of a
package, I don't care if that build_number happened to be a released version or a dev version
However, to specify that dependency you're going to need a way to represent the build number as part of a requirement string, at which point we're right back where we started.
Perhaps. I'm wondering if the separation of "version" (does not include the ".dev") and "build_number" helps clear up some of the cases.
If "1.2.3.dev456"-type version strings don't appear in packages released to PyPI, then the job of the downstream RPM/.deb packagers is easier (they then don't need to care about the spelling of the version with the build number). Have a "RationalReleaseVersion()" that is just the non-dev part of the proposal.
Yes, as you say, the requirement/dependency fields (presumably they will be strings) need a way to spell the "build_number" part. However, the large set of setup.py authors that don't need to understand or use dependency strings don't need to see that.
Trent
Trent Mick trentm@gmail.com writes:
Perhaps. I'm wondering if the separation of "version" (does not include the ".dev") and "build_number" helps clear up some of the cases.
If they are separate components (where each component from left to right is entirely subordinate to the preceding component), then that separation is implied. Version ‘1.2.3’ can have as many ‘.devXXXX’ as desired, all of which will compare previous to version ‘1.2.4’.
If "1.2.3.dev456"-type version strings don't appear in packages released to PyPI, then the job of the downstream RPM/.deb packagers is easier (they then don't need to care about the spelling of the version with the build number).
If the version comparison semantics are such that simple “compare non-digits per ASCII, compare digit sequences as integers” works within a component, I'm not aware of any distribution downstream that can't just use them as-is. What specific problems can you see with that?
Have a "RationalReleaseVersion()" that is just the non-dev part of the proposal.
Let's choose a name that doesn't add to the confusion between the non-number “version string” and the mathematical concept of “rational number”. Perhaps ‘SimpleVersion’ is a better name.
Ben Finney wrote:
If they are separate components (where each component from left to right is entirely subordinate to the preceding component), then that separation is implied. Version ‘1.2.3’ can have as many ‘.devXXXX’ as desired, all of which will compare previous to version ‘1.2.4’.
This demonstrates the "count up from" versus "count up to" problem. If I'm getting ready to release 1.2.4, I think I'm working on 1.2.4-dev20090611 (or similar), not that I'm working on 1.2.3.9999.3.
If the version comparison semantics are such that simple “compare non-digits per ASCII, compare digit sequences as integers” works within a component, I'm not aware of any distribution downstream that can't just use them as-is. What specific problems can you see with that?
I think the "count up to" a release version is the problem, and the only one I can think of. Before Twisted releases 8.2.2, do they really need to call all of the versions 8.2.1.99.1, 8.2.1.99.2, etc., to avoid confusion with a possible 8.2.1 release? Don't you think some information is lost by not conveying "this will become 8.2.2 when it is the release version"? I grant you that your comparison scheme with version components works for the computer, I just think it loses information that's important to humans.
And as others have said, I too use these development version numbers in internal build tools which automatically update dependencies, so I am comparing version numbers.
Have a "RationalReleaseVersion()" that is just the non-dev part of the proposal.
Let's choose a name that doesn't add to the confusion between the non-number “version string” and the mathematical concept of “rational number”. Perhaps ‘SimpleVersion’ is a better name.
I agree on "Rational" being confusing. "SimpleVersion" sounds reasonable to me.
Eric.
Eric Smith eric@trueblade.com writes:
Ben Finney wrote:
If the version comparison semantics are such that simple “compare non-digits per ASCII, compare digit sequences as integers” works within a component, I'm not aware of any distribution downstream that can't just use them as-is. What specific problems can you see with that?
I think the "count up to" a release version is the problem, and the only one I can think of. Before Twisted releases 8.2.2, do they really need to call all of the versions 8.2.1.99.1, 8.2.1.99.2, etc., to avoid confusion with a possible 8.2.1 release? Don't you think some information is lost by not conveying "this will become 8.2.2 when it is the release version"?
Why is it necessary for a version string to convey a prediction about what *future* version strings will mean? That seems to me to be an overloading that costs a significant amount of complexity, and is unnecessary since a different version string can be chosen that meets the intentional sequence position anyway.
"P.J. Eby" pje@telecommunity.com writes:
Please explain how you intend to designate "development" versions that compare less than the equivalent non-development versions in your scheme.
>>> (V("0.9") ... < V("0.9.0") ... < V("0.9.1") ... < V("0.9.a") ... < V("0.9.a2") ... < V("0.9.post123") ... < V("0.9b") ... < V("0.10") ... < V("0.999.0.dev-r925") ... < V("0.999.0.dev-r1357") ... < V("0.999.0.dev-r2468") ... < V("0.999.0.dev-r3579") ... < V("0.999.alpha1") ... < V("0.999.alpha2") ... < V("0.999.beta1") ... < V("0.999.rc1") ... < V("0.999.rc2") ... < V("1.0")) ... True
"P.J. Eby" pje@telecommunity.com writes:
I can *almost* see a case for dropping "post" […]
However, I do not see an equivalent case for dropping "dev", since it's an important part of development workflows, and I don't see any way to simulate it in an an otherwise-linear scheme.
I don't understand. You see that there's a scheme for generating version strings that compare in a linear sequence, yet you can't see how to generate a version string that will compare at a specific point in that linear sequence?
For my part, I don't see what it is about these workflows that requires a special-cased token in the version string. Why can't the workflow simply use version strings that compare linearly as specified?
Paul Moore p.f.moore@gmail.com writes:
One other aspect of standard practice that I just realised your rules don't cover is where version strings differ in length. The normal lexicographic "shortest is earliest" rule doesn't work properly:
1.2a1 vs 1.2 (I hope everyone agrees that 1.2a1 is earlier)
No, I don't agree. Those each represent two components, where the first is identical and the second is different; and when comparing the two different components, I would expect “2” to be earlier than “2a1”.
On Sun, 14 Jun 2009 09:46:17 +1000, Ben Finney ben+python@benfinney.id.au wrote:
Eric Smith eric@trueblade.com writes:
Ben Finney wrote:
If the version comparison semantics are such that simple “compare non-digits per ASCII, compare digit sequences as integers” works within a component, I'm not aware of any distribution downstream that can't just use them as-is. What specific problems can you see with that?
I think the "count up to" a release version is the problem, and the only one I can think of. Before Twisted releases 8.2.2, do they really need to call all of the versions 8.2.1.99.1, 8.2.1.99.2, etc., to avoid confusion with a possible 8.2.1 release? Don't you think some information is lost by not conveying "this will become 8.2.2 when it is the release version"?
Why is it necessary for a version string to convey a prediction about what *future* version strings will mean? That seems to me to be an overloading that costs a significant amount of complexity, and is unnecessary since a different version string can be chosen that meets the intentional sequence position anyway.
I think there was some confusion here. Twisted doesn't use the "count up to" a release scheme (which is the .devNNN scheme). It uses the "count away from" a release scheme (ie, the equivalent of the .postNNN scheme, if I understand correctly).
The current "in development version" of Twisted is 8.2.0r27007. The last release was Twisted 8.2.0. It is expected, but not guaranteed, that the next release of Twisted will be 9.0.0.
Projects that use the .devNNN scheme, though, rather than something like the .postNNN scheme, do have to deal with this, though. It seems to me that this is pretty common, as release candidates will necessarily fall into this category (however, it is far past my bed time, so if I have forgotten about some corner of things, apologies for the noise).
[snip]
Paul Moore p.f.moore@gmail.com writes:
One other aspect of standard practice that I just realised your rules don't cover is where version strings differ in length. The normal lexicographic "shortest is earliest" rule doesn't work properly:
1.2a1 vs 1.2 (I hope everyone agrees that 1.2a1 is earlier)
No, I don't agree. Those each represent two components, where the first is identical and the second is different; and when comparing the two different components, I would expect “2” to be earlier than “2a1”.
This seems to be the crux of the use case. 1.2a1 obviously should come before 1.2. :) Forcing the first alpha release of 1.2 to be 1.1.999.a1 or something like that would be very unfortunate, even though from some perspectives it's simpler than the reverse.
Jean-Paul
2009/6/14 Ben Finney ben+python@benfinney.id.au:
Paul Moore p.f.moore@gmail.com writes:
One other aspect of standard practice that I just realised your rules don't cover is where version strings differ in length. The normal lexicographic "shortest is earliest" rule doesn't work properly:
1.2a1 vs 1.2 (I hope everyone agrees that 1.2a1 is earlier)
No, I don't agree. Those each represent two components, where the first is identical and the second is different; and when comparing the two different components, I would expect “2” to be earlier than “2a1”.
I don't think it's possible to get away with 1.2a1 sorting after 1.2.
At the bare minimum, the Python core version numbering needs to be supported IMHO. (Not because it's going to be used frequently in this context, but because it's the base model that all Python extension authors will be familiar with, and so most likely to be what they base any further extensions on).
Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ben Finney wrote:
Eric Smith eric@trueblade.com writes:
Ben Finney wrote:
If the version comparison semantics are such that simple “compare non-digits per ASCII, compare digit sequences as integers” works within a component, I'm not aware of any distribution downstream that can't just use them as-is. What specific problems can you see with that?
I think the "count up to" a release version is the problem, and the only one I can think of. Before Twisted releases 8.2.2, do they really need to call all of the versions 8.2.1.99.1, 8.2.1.99.2, etc., to avoid confusion with a possible 8.2.1 release? Don't you think some information is lost by not conveying "this will become 8.2.2 when it is the release version"?
Why is it necessary for a version string to convey a prediction about what *future* version strings will mean? That seems to me to be an overloading that costs a significant amount of complexity, and is unnecessary since a different version string can be chosen that meets the intentional sequence position anyway.
"P.J. Eby" pje@telecommunity.com writes:
Please explain how you intend to designate "development" versions that compare less than the equivalent non-development versions in your scheme.
>>> (V("0.9") ... < V("0.9.0") ... < V("0.9.1") ... < V("0.9.a") ... < V("0.9.a2") ... < V("0.9.post123") ... < V("0.9b") ... < V("0.10") ... < V("0.999.0.dev-r925") ... < V("0.999.0.dev-r1357") ... < V("0.999.0.dev-r2468") ... < V("0.999.0.dev-r3579") ... < V("0.999.alpha1") ... < V("0.999.alpha2") ... < V("0.999.beta1") ... < V("0.999.rc1") ... < V("0.999.rc2") ... < V("1.0")) ... True"P.J. Eby" pje@telecommunity.com writes:
I can *almost* see a case for dropping "post" […]
However, I do not see an equivalent case for dropping "dev", since it's an important part of development workflows, and I don't see any way to simulate it in an an otherwise-linear scheme.
I don't understand. You see that there's a scheme for generating version strings that compare in a linear sequence, yet you can't see how to generate a version string that will compare at a specific point in that linear sequence?
For my part, I don't see what it is about these workflows that requires a special-cased token in the version string. Why can't the workflow simply use version strings that compare linearly as specified?
Paul Moore p.f.moore@gmail.com writes:
One other aspect of standard practice that I just realised your rules don't cover is where version strings differ in length. The normal lexicographic "shortest is earliest" rule doesn't work properly:
1.2a1 vs 1.2 (I hope everyone agrees that 1.2a1 is earlier)
No, I don't agree. Those each represent two components, where the first is identical and the second is different; and when comparing the two different components, I would expect “2” to be earlier than “2a1”.
- -1: "practicality beats purity" here: there is *no* case in which an alpha version should *ever* sort after the final release with the corresponding number. If we specify the "simple pure" scheme you propose, nobody will use it, period.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Tres Seaver tseaver@palladion.com writes:
-1: "practicality beats purity" here: there is *no* case in which an alpha version should *ever* sort after the final release with the corresponding number. If we specify the "simple pure" scheme you propose, nobody will use it, period.
Well then, I don't see a way forward on the issue of helping distributors to manage version numbers sanely. I don't know of any operating system package manager that returns different comparison results depending on what specific letters are used in the version string.
All this specialness-of-certain-letters may make sense to Python core developers, but it's just going to result in nonsensical version progressions as far as operating system distributors are concerned. What will be the resolution there?
On Mon, Jun 15, 2009 at 08:10:05PM +1000, Ben Finney wrote:
Tres Seaver tseaver@palladion.com writes:
-1: "practicality beats purity" here: there is *no* case in which an alpha version should *ever* sort after the final release with the corresponding number. If we specify the "simple pure" scheme you propose, nobody will use it, period.
Well then, I don't see a way forward on the issue of helping distributors to manage version numbers sanely. I don't know of any operating system package manager that returns different comparison results depending on what specific letters are used in the version string.
All this specialness-of-certain-letters may make sense to Python core developers, but it's just going to result in nonsensical version progressions as far as operating system distributors are concerned. What will be the resolution there?
Alpha, beta and release candidate releases have been around for ages and I imagine most distributors have figured out a way of coping with this.
In Debian's case 1.0a1 would become 1.0~a1 for example (IIRC), which sorts before 1.0.
Regards Floris
Floris Bruynooghe floris.bruynooghe@gmail.com writes:
On Mon, Jun 15, 2009 at 08:10:05PM +1000, Ben Finney wrote:
Well then, I don't see a way forward on the issue of helping distributors to manage version numbers sanely. I don't know of any operating system package manager that returns different comparison results depending on what specific letters are used in the version string.
Alpha, beta and release candidate releases have been around for ages and I imagine most distributors have figured out a way of coping with this.
That doesn't answer the point raised, though. Isn't a major reason for all this work to help the downstream distributors to help migrate *away* from munging version strings and toward version strings that compare sanely as-is?
In Debian's case 1.0a1 would become 1.0~a1 for example (IIRC), which sorts before 1.0.
That's exactly the sort of hack I would hope would no longer be necessary for version strings formed under an improved version comparison specification.
Forgive me for saying so, but this looks strongly like abandoning the criterion of “make it easier for distributors than it is at present”.
On Mon, 15 Jun 2009 23:08:33 +1000, Ben Finney ben+python@benfinney.id.au wrote:
Floris Bruynooghe floris.bruynooghe@gmail.com writes:
On Mon, Jun 15, 2009 at 08:10:05PM +1000, Ben Finney wrote:
Well then, I don't see a way forward on the issue of helping distributors to manage version numbers sanely. I don't know of any operating system package manager that returns different comparison results depending on what specific letters are used in the version string.
Alpha, beta and release candidate releases have been around for ages and I imagine most distributors have figured out a way of coping with this.
That doesn't answer the point raised, though. Isn't a major reason for all this work to help the downstream distributors to help migrate *away* from munging version strings and toward version strings that compare sanely as-is?
In Debian's case 1.0a1 would become 1.0~a1 for example (IIRC), which sorts before 1.0.
That's exactly the sort of hack I would hope would no longer be necessary for version strings formed under an improved version comparison specification.
Forgive me for saying so, but this looks strongly like abandoning the criterion of “make it easier for distributors than it is at present”.
By having this standard, distributors do have an easier time. They can transform these version numbers automatically, just as they do many other things to upstream packages automatically to turn them into a distro package.
So no, the goal of making it easier for distributors is not being abandoned.
Jean-Paul
On Mon, Jun 15, 2009 at 3:24 PM, Jean-Paul Calderoneexarkun@divmod.com wrote:
Forgive me for saying so, but this looks strongly like abandoning the criterion of “make it easier for distributors than it is at present”.
By having this standard, distributors do have an easier time. They can transform these version numbers automatically, just as they do many other things to upstream packages automatically to turn them into a distro package.
So no, the goal of making it easier for distributors is not being abandoned.
Absolutely,
I let's not forget that this proposal will provide a standard for people to ve
On Mon, Jun 15, 2009 at 3:31 PM, Tarek Ziadéziade.tarek@gmail.com wrote:
On Mon, Jun 15, 2009 at 3:24 PM, Jean-Paul Calderoneexarkun@divmod.com wrote:
Forgive me for saying so, but this looks strongly like abandoning the criterion of “make it easier for distributors than it is at present”.
By having this standard, distributors do have an easier time. They can transform these version numbers automatically, just as they do many other things to upstream packages automatically to turn them into a distro package.
So no, the goal of making it easier for distributors is not being abandoned.
Absolutely,
I let's not forget that this proposal will provide a standard for people to ve
oups, sent too early
I won't comment on this week mails yet, I lost track of the discussions so I need to read them. But I wanted to react on this:
Let's not forget that this proposal will provide a standard for people to version their packages in a way that is directly compatible for distributions out there,
The final goal is to write some statement like this in the python distutils doc:
"Hey, if you want to have a distributions-friendly package, you might want to use this tool for your version numbers, it's proven to work on most packaging systems out there"
People will be free not to follow it of course if they don't distribute their packages, and this will not change their lives.
Regards Tarek
Tres Seaver wrote:
Ben Finney wrote:
Eric Smith eric@trueblade.com writes:
Ben Finney wrote:
If the version comparison semantics are such that simple compare non-digits per ASCII, compare digit sequences as integers works within a component, I'm not aware of any distribution downstream that can't just use them as-is. What specific problems can you see with that?
I think the "count up to" a release version is the problem, and the only one I can think of. Before Twisted releases 8.2.2, do they really need to call all of the versions 8.2.1.99.1, 8.2.1.99.2, etc., to avoid confusion with a possible 8.2.1 release? Don't you think some information is lost by not conveying "this will become 8.2.2 when it is the release version"?
Why is it necessary for a version string to convey a prediction about what *future* version strings will mean? That seems to me to be an overloading that costs a significant amount of complexity, and is unnecessary since a different version string can be chosen that meets the intentional sequence position anyway.
"P.J. Eby" pje@telecommunity.com writes:
Please explain how you intend to designate "development" versions that compare less than the equivalent non-development versions in your scheme.
>>> (V("0.9") ... < V("0.9.0") ... < V("0.9.1") ... < V("0.9.a") ... < V("0.9.a2") ... < V("0.9.post123") ... < V("0.9b") ... < V("0.10") ... < V("0.999.0.dev-r925") ... < V("0.999.0.dev-r1357") ... < V("0.999.0.dev-r2468") ... < V("0.999.0.dev-r3579") ... < V("0.999.alpha1") ... < V("0.999.alpha2") ... < V("0.999.beta1") ... < V("0.999.rc1") ... < V("0.999.rc2") ... < V("1.0")) ... True"P.J. Eby" pje@telecommunity.com writes:
I can *almost* see a case for dropping "post" [&]
However, I do not see an equivalent case for dropping "dev", since it's an important part of development workflows, and I don't see any way to simulate it in an an otherwise-linear scheme.
I don't understand. You see that there's a scheme for generating version strings that compare in a linear sequence, yet you can't see how to generate a version string that will compare at a specific point in that linear sequence?
For my part, I don't see what it is about these workflows that requires a special-cased token in the version string. Why can't the workflow simply use version strings that compare linearly as specified?
Paul Moore p.f.moore@gmail.com writes:
One other aspect of standard practice that I just realised your rules don't cover is where version strings differ in length. The normal lexicographic "shortest is earliest" rule doesn't work properly:
1.2a1 vs 1.2 (I hope everyone agrees that 1.2a1 is earlier)
No, I don't agree. Those each represent two components, where the first is identical and the second is different; and when comparing the two different components, I would expect 2 to be earlier than 2a1 .
-1: "practicality beats purity" here: there is *no* case in which an alpha version should *ever* sort after the final release with the corresponding number.
I thought improved support for OS packagers was one of the main rationale for this version scheme ? In that case, the above scheme is totally incompatible with what at least dpkg, and I would assume rpm, use for version comparison:
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
I am a bit confused, because I thought several packagers were there at PyCon to discuss about this ?
David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Trent Mick wrote:
- when I specify a dependency against a particular build_number of a
package, I don't care if that build_number happened to be a released version or a dev version
However, to specify that dependency you're going to need a way to represent the build number as part of a requirement string, at which point we're right back where we started.
Perhaps. I'm wondering if the separation of "version" (does not include the ".dev") and "build_number" helps clear up some of the cases.
If "1.2.3.dev456"-type version strings don't appear in packages released to PyPI, then the job of the downstream RPM/.deb packagers is easier (they then don't need to care about the spelling of the version with the build number). Have a "RationalReleaseVersion()" that is just the non-dev part of the proposal.
Yes, as you say, the requirement/dependency fields (presumably they will be strings) need a way to spell the "build_number" part. However, the large set of setup.py authors that don't need to understand or use dependency strings don't need to see that.
Assuming that we add the requisite 'build_number' field to PKG_INFO, could we allow spelling a dependency on a combined version + build number using an "odd" spelling, such as: '1.2.3#4567' or '1.2.3@4567'? This spelling would be *disallowed* for "released" packages, but could still satisfy the folks who use such dependencies in internal-only development mode.
Effectively, my proposal here is to move the whole "build_number" topic out of the PEP 386 (which is about versioning), and into PEP 345 (whichadds dependencies on distributions to PKG_INFO).
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
At 09:11 PM 6/11/2009 -0400, Tres Seaver wrote:
Assuming that we add the requisite 'build_number' field to PKG_INFO, could we allow spelling a dependency on a combined version + build number using an "odd" spelling, such as: '1.2.3#4567' or '1.2.3@4567'?
And if we make that special string "dev" or "post", then we get backwards compatibility and upgrade options for setuptools users, too. Great idea. ;-)
This spelling would be *disallowed* for "released" packages, but could still satisfy the folks who use such dependencies in internal-only development mode.
I don't see what usefulness such a disallowal would have. PyPI already accepts all sorts of stupid versions, including ones even setuptools can't make any sense of. And for packages installed on the machine, the build information is still going to need to be in any generated filenames, such as that of the .egg-info directory or the egg file itself.
On Thu, Jun 11, 2009 at 6:48 PM, P.J. Ebypje@telecommunity.com wrote:
I don't see what usefulness such a disallowal would have.
The sanity of other people browsing through and trying to grok the versions of packages released to PyPI.
PyPI already accepts all sorts of stupid versions, including ones even setuptools can't make any sense of.
That's not a feature. :)
Trent
On Thu, Jun 11, 2009 at 09:11:38PM -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Trent Mick wrote:
- when I specify a dependency against a particular build_number of a
package, I don't care if that build_number happened to be a released version or a dev version
However, to specify that dependency you're going to need a way to represent the build number as part of a requirement string, at which point we're right back where we started.
Perhaps. I'm wondering if the separation of "version" (does not include the ".dev") and "build_number" helps clear up some of the cases.
If "1.2.3.dev456"-type version strings don't appear in packages released to PyPI, then the job of the downstream RPM/.deb packagers is easier (they then don't need to care about the spelling of the version with the build number). Have a "RationalReleaseVersion()" that is just the non-dev part of the proposal.
Yes, as you say, the requirement/dependency fields (presumably they will be strings) need a way to spell the "build_number" part. However, the large set of setup.py authors that don't need to understand or use dependency strings don't need to see that.
Assuming that we add the requisite 'build_number' field to PKG_INFO, could we allow spelling a dependency on a combined version + build number using an "odd" spelling, such as: '1.2.3#4567' or '1.2.3@4567'? This spelling would be *disallowed* for "released" packages, but could still satisfy the folks who use such dependencies in internal-only development mode.
PyPI needs to allow any version anyway, so these things will end up being used there and make the situation only worse. The .devX and .postX allow for both people counting up to and counting away from releases and if combinations (.postX.devY) are disallowed I think it's quite clear and straight forward. Bear in mind no-one forces you to use those suffixes. If you never want to see them just don't use them. You can happily cope with just normal alpha, beta and release candidate releases.
Regards Floris
-
Ben Finney -
David Cournapeau -
Eric Smith -
Floris Bruynooghe -
Jean-Paul Calderone -
P.J. Eby -
Paul Moore -
Tarek Ziadé -
Trent Mick -
Tres Seaver