[Distutils] RFC : Version comparison

P.J. Eby 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 mailing list