[Distutils] RFC : Version comparison
pje at telecommunity.com
Thu May 14 04:08:18 CEST 2009
At 02:34 PM 5/13/2009 +0200, Tarek Ziadé wrote:
>Any feedback on this "dev version of post release" use case
It looks like the 'suggest' function doesn't handle svn revisions
properly for conversion from setuptools versions. Setuptools '-r###'
is a post-release tag, as is any alpha string alphabetically after
'final'. That is, '0.4a1.r10' is actually '0.4a1.post10'. (Notice,
for example, that setuptools' trunk version is '0.7a1dev-r66608'.)
for the full syntax; I'm a bit concerned that there may be other
incorrect interpretations taking place in this function. (Notice,
for example, that a '-' in a version number indicates a post-release,
but your code is treating '-' as identical to '.'.)
>or I move
>forward and integrate it ?
Into the stdlib? I'm a bit surprised that something with such global
consequences is having its bleeding edge development done in the
stdlib, rather than as an external package.
I sort of assumed at first the idea was to provide a normalized or
canonical form for setuptools versions, but of course it's a bit more
restrictive than that, and at the moment the only mapping between the
two seems broken -- and in a way that suggests the designers neither
read the setuptools version documentation nor examined what people
were actually doing with their versioning schemes.
To be clear, I'm not opposed to blessing a normalized version scheme
-- there are solid benefits to doing such a thing. I'm opposed to
putting one in the stdlib without a clear rationale for the choices,
and an upgrade path that either lets setuptools users ignore the new
scheme, or gives them some benefit for switching.
Meanwhile, I haven't seen any indication that this new format is
easier for non-Python tools to parse. Is the plan for other tools to
use the stdlib parsing code, because I don't see how existing tools
like RPM et al could use the proposed scheme.
More information about the Distutils-SIG