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

[Phillip J. Eby]

At 12:02 PM 8/4/2008 -0500, Dave Peterson wrote:
>Phillip J. Eby wrote:
>>At 07:05 PM 7/30/2008 -0500, Dave Peterson 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'.
>>>
>>>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.
>>
>>This is what 'rc' tags are for, actually.  You can put your version 
>>in the source, and use the -b option to egg_info while doing builds 
>>and testing to tack on an 'rc' tag, possibly with a subversion number as well.
>
>Perhaps I'm missing something, but that doesn't seem like it scales 
>to a community -- not everyone is going to remember to use a '-b' 
>option when building and that is going to cause endless support problems.

Only the creator of a release uses that; the community should never 
be building "release" versions.


>    We do put the following in our setup.cfg so that people don't 
> mistakenly build release versions when not intending to do so:
>
>[egg_info]
>tag_build = .dev
>tag_svn_revision = 1
>
>Are you staying the standard process for setuptools is to delete / 
>modify this when tagging a release in the repo?

I personally don't tag releases in the repository; a release is not a 
tag.  I have an alias called 'release' that maps to 'egg_info -Rdb 
""', and I use it when issuing release builds.

However, there's nothing stopping you from creating a utility that 
copies the trunk to a tag, checks out the tag, removes the options, 
and checks in the tag, if that would be your preferred approach.


>   If not, how do you avoid the problem of someone building from a 
> source checkout and finding out that 3.0.dev-r1234 doesn't satisfy 
> the '>= 3.0b1' dependency spec?

I bump the version number in SVN immediately after making a release, 
so that the trunk would be '3.1.dev-r1234', not '3.0dev'.  If you're 
using .dev tags in your egg-info setup, you should bump the version 
in setup.py immediately *after* releasing, to avoid just this situation.