[Distutils] Bug in setuptools version parsing when appending '.dev'?
dpeterson at enthought.com
Mon Aug 4 19:02:01 CEST 2008
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')
>> >>> pv('1.0a1') < pv('1.0')
>> >>> pv('1.0a1.dev') < pv('1.0.dev')
>> >>> pv('1.0a1') < pv('1.0.dev')
>> >>> import setuptools
>> >>> setuptools.__version__
>> 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
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. We do
put the following in our setup.cfg so that people don't mistakenly build
release versions when not intending to do so:
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? 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?
More information about the Distutils-SIG