Re: [Distutils] RFC : Version comparison

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.

2009/5/14 P.J. Eby <pje@telecommunity.com>:
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
Ok I'll check that
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.
PEP 345 is being rewritten with a rationale specification of versions in mind, and the plan is to refer to this version scheme and document it there. see http://svn.python.org/view/peps/branches/jim-update-345/pep-0345.txt?view=ma... from a setuptools user point of view, the benefit I can see is that they will have better version numbers that will comply with a documented standard, that is usable and understandable by os packagers for example. Now I suppose setuptools will have to propose both for some time, but in Distutils, no one really uses LooseVersion and StricVersion, so the idea is to deprecated them and introduce the new one in there. But what I am scared of is : who will work on setuptools side ? can you bless someone to do the work when we agree on a common roadmap ?
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.
Some people from Fedora and Ubuntu worked on this (I've CC them) , and the whole idea was to provide a scheme that would make rpm and debian packagers happy with it. I am not a RPM expert at all, but the output is supposed to be RPM-friendly. Toshio ? Regards Tarek -- Tarek Ziadé | http://ziade.org

2009/5/14 P.J. Eby <pje@telecommunity.com>:
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 '.'.)
Ok, I have changed the suggest function accordingly, def test_suggest_rational_version(self): self.assertEquals(suggest('1.0'), '1.0') self.assertEquals(suggest('1.0-alpha1'), '1.0a1') self.assertEquals(suggest('1.0rc2'), '1.0c2') self.assertEquals(suggest('walla walla washington'), None) # from setuptools self.assertEquals(suggest('0.4a1.r10'), '0.4a1.post10') self.assertEquals(suggest('0.7a1dev-r66608'), '0.7a1.dev66608') self.assertEquals(suggest('0.6a9.dev-r41475'), '0.6a9.dev41475') self.assertEquals(suggest('2.4preview1'), '2.4c1') self.assertEquals(suggest('2.4rc1'), '2.4c1') self.assertEquals(suggest('2.4pre1') , '2.4c1') self.assertEquals(suggest('2.1-rc2'), None) # no suggestion Tarek -- Tarek Ziadé | http://ziade.org
participants (2)
-
P.J. Eby
-
Tarek Ziadé