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'.) See http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s... 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.