[Distutils] Bug in setuptools version parsing when appending '.dev'?
dpeterson at enthought.com
Mon Aug 4 19:24:58 CEST 2008
Alexander Michael wrote:
> On Wed, Jul 30, 2008 at 8:05 PM, Dave Peterson <dpeterson at enthought.com> wrote:
>> Am I missing something or is the following a bug whereby adding the '.dev'
>> tag is doing something weird?
>>>>> from pkg_resources import parse_requirement as pv
>>>>> pv('1.0a1.dev') < pv('1.0a1')
>>>>> pv('1.0a1') < pv('1.0')
>>>>> pv('1.0a1.dev') < pv('1.0.dev')
>>>>> pv('1.0a1') < pv('1.0.dev')
>>>>> import setuptools
>> This is mainly causing us problems when projects try to track alpha and beta
>> level bumps in dependencies, such as when project Foo requires project Bar
>> version 3.0b1 via a requirement like 'Bar >= 3.0b1' (which means we don't
>> want the development prereleases of Bar's first beta release, but anything
>> after that should be okay.) But then when we actually want to release Bar
>> 3.0 and change the version number to just '3.0', suddenly installs fail
>> while we try to run the last set of tests because '3.0.dev' is older than
> This looks wrong to me too. One would think that the development
> version 3 (final) would be newer than any 3.beta version. But both dev
> and b are pre-release tags with dev being explicitly mapped to '@' in
> the parsed version so that it is treated as younger than beta:
> In : v('3.0.dev')
> Out: ('00000003', '*@', '*final')
> In : v('3.0b1')
> Out: ('00000003', '*b', '00000001', '*final')
> The rationale is probably that dev releases represent "early"
> development releases, while beta releases are closer to the final
> release than dev releases. What I think is missing is a way of saying
> (silently) that this a dev of the final, and that final is newer than
> beta (and especially a dev of a beta).
Actually, you can append the tag 'final' and it seems to work fine:
>>> pv('3.0.final.dev') > pv(3.0b1')
I just hate to add the tag 'final' to a final release due to the extra
typing it causes people. It seems to me the community expectation is
to be able to do things like "easy_install Traits==3.0" rather than
>> If it is not a bug, how do you handle situations where you want to run that
>> last round of testing prior to tagging and building releases? I'd rather do
>> that AFTER making all source changes, and not have to change the version
>> number after the testing.
> To work with what we have now, I think you need to set the trunk
> version to 3b2.dev (the next in-development version). And then when
> you're ready for the final version of 3, bump your working copy of the
> trunk to 3 (final) and do a test build with the .dev dropped (perhaps
> from the command-line with python setup.py egg_info -RDb "" sdist
> bdist_egg) in a virtualenv or similar sandbox where you can easily
> manually wipe site-packages in case you need to iterate. Once that's
> good, commit, branch and tag, release, and then immediately commit the
> trunk version to 3.1.dev (3.0.1 bug-fix releases will be prepared in
> the branch).
The problem here is that we *released* Traits 3.0. It is no longer a
beta. But other projects that wanted to rely on it as soon as it was in
a stable beta put in a requirement of "Traits >=3.0b1". Unfortunately,
if developers check-out the tag of the release and do a build, they get
Traits with version "3.0.dev-rXXXXX' which setuptools says doesn't
satisfy "Traits >=3.0b1". They get the '.dev' because we have
historically not modified the source's setup.cfg when tagging the
release (we do NO changes between the last build/test cycle and the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG