[Distutils] Bug in setuptools version parsing when appending '.dev'?

[Dave Peterson]

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')
>>>>>           
>> True
>>     
>>>>> pv('1.0a1') < pv('1.0')
>>>>>           
>> True
>>     
>>>>> pv('1.0a1.dev') < pv('1.0.dev')
>>>>>           
>> False
>>     
>>>>> pv('1.0a1') < pv('1.0.dev')
>>>>>           
>> False
>>     
>>>>> import setuptools
>>>>> setuptools.__version__
>>>>>           
>> '0.6c8'
>>
>> 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
>> '3.0b1'.
>>     
>
> 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 [2]: v('3.0.dev')
> Out[2]: ('00000003', '*@', '*final')
>
> In [3]: v('3.0b1')
> Out[3]: ('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')
True

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 
"easy_install Traits==3.0.final"


>> 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 
tagging.)


-- Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080804/7a115753/attachment.htm>