[Distutils] Bug in setuptools version parsing when appending '.dev'?
Phillip J. Eby
pje at telecommunity.com
Tue Aug 5 00:32:07 CEST 2008
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')
>>> >>> 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 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:
>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.
More information about the Distutils-SIG