Re: [Distutils] post-release revisions
At 03:48 PM 6/11/2009 +0100, Paul Moore wrote:
Please note, in case I seem excessively aggressive - my assumption is that the standard defined by the PEP doesn't have to be used by everyone, in all cases. You presumably have code that works at the moment, and you are perfectly entitled to continue using it.
That depends on whether this PEP's version scheme is also going to be embedded in the code implied by PEP 376. If so, then nobody will have any reason to switch from using pkg_resources to the PEP 376 pkgutil code, because they won't be able to manage their test, dev, and collaboration environments that way.
If you switch to the APIs proposed in the PEP, then presumably you see some benefits in following the standard.
That's precisely it - there aren't any visible benefits to doing so, but there *are* visible problems. We need to have a way to translate existing version schemes to the new one, if we're to be able to have a reasonable upgrade path -- considering that these PEPs' only benefit to adopters (at least among those using setuptools) is that the code will be in some future stdlib version, and support simple uninstalls.
"P.J. Eby"
That depends on whether this PEP's version scheme is also going to be embedded in the code implied by PEP 376. If so, then nobody will have any reason to switch from using pkg_resources to the PEP 376 pkgutil code, because they won't be able to manage their test, dev, and collaboration environments that way.
What prevents them from doing so merely by choosing version strings that conform to the specification?
That's precisely it - there aren't any visible benefits to doing so, but there *are* visible problems.
I think a significant benefit will be that the version comparison semantics will be implemented *in Python*, and I know there are very many people who would like to drop a dependency on third-party tools. Alternatively, if this version string scheme is to be implemented in PEP 365, that has the same effect: it will be “part of Python”, which is a huge benefit compared to an implementation outside Python.
We need to have a way to translate existing version schemes to the new one, if we're to be able to have a reasonable upgrade path --
This certainly deserves consideration. However, I remind readers that part of the problem we're trying to solve here is that version string schemes are *already* non-standard and inconsistent; we would have to choose only a sub-set of existing version schemes to be supported for upgrade. -- \ “In the long run, the utility of all non-Free software | `\ approaches zero. All non-Free software is a dead end.” —Mark | _o__) Pilgrim, 2006 | Ben Finney
At 08:39 AM 6/12/2009 +1000, Ben Finney wrote:
However, I remind readers that part of the problem we're trying to solve here is that version string schemes are *already* non-standard and inconsistent; we would have to choose only a sub-set of existing version schemes to be supported for upgrade.
Indeed, and such a subset has already been proposed. Apparently, some people don't like "dev" and "post" being a part of it. I can *almost* see a case for dropping "post" - I personally have not used it, and Trent has shown evidence that its usage is relatively rare. And I could *almost* see tacking on extra zeros to signify a post tag, at the cost of readability, and the need for any tracked packages (where the Python version of the project is versioned as patchlevels of the foreign project) to maintain a consistent numbering scheme. 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.
P.J. Eby wrote:
I can *almost* see a case for dropping "post" - I personally have not used it, and Trent has shown evidence that its usage is relatively rare. And I could *almost* see tacking on extra zeros to signify a post tag, at the cost of readability, and the need for any tracked packages (where the Python version of the project is versioned as patchlevels of the foreign project) to maintain a consistent numbering scheme.
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 agree with both of these: you can simulate "post" by adding another dot and a number (or string), but we still need "dev". I'm okay with dropping "post", leaving "dev" as the only special case. Eric.
participants (3)
-
Ben Finney -
Eric Smith -
P.J. Eby