[Distutils] Bug in setuptools version parsing when appending '.dev'?
dpeterson at enthought.com
Wed Aug 6 19:15:30 CEST 2008
Phillip J. Eby wrote:
> 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
> Only the creator of a release uses that; the community should never be
> building "release" versions.
Right, and that's the exact problem! They're grabbing the source via
svn checkout from the release tag and doing their own build which ends
up getting labeled as '3.0.dev-r1234' (which seems to be exactly the
right thing to say to me -- it is an svn build of the 3.0 release) but
this does not satisfy dependencies that are in other projects that were
put out requiring "Traits >= 3.0b1". Sure I can tell people not to do
that when they say it doesn't work, but I think it should work because
the pattern works everywhere else (see below.)
>> 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.
Great to hear about what you do, but we frequently have to support
customers who need minor updates and having a tag that makes it easy to
branch from, or re-create, a release is a very useful thing. We have to
many developers who need to restart at a release point to be able to
track the code state at release points using any other method we've seen.
> 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.
Hmm, and I thought I was clear saying that this is exactly what I do not
want to do. :-) Ideally, we don't want to modify tags in anyway.
Like you pointed out above, I don't want people accidentally building
'release' versions except the project maintainers.
>> 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.
We DO do that. That doesn't solve the problem I'm talking about
though. Let me try one more time....
There exist people who prefer to build from source they've gotten from
the svn repo. These people don't want to worry about bugs in the trunk
/ development version so they go grab the source from the latest release
tag. They then do a "setup.py bdist_egg" to build an egg that they
plan to distribute within their company, work group, what have you as
part of their shared project where they defined dependencies as
">=3.0b1" While the latest tagged version is 3.0b1, 3.0b2, 3.0c1,
3.0c2, etc. this process works great as all of those are correctly newer
or equal to 3.0b1 even when .dev tags are appended to the version
number. BUT, as soon as we tag and release the final 3.0 release, it
breaks because 3.0.dev < 3.0b1. It will work fine again when we tag
and release 3.1<anything> or 4.0<anything>. It is only the final
release of 3.0 that exhibits this problem.
This seems like a bug.
More information about the Distutils-SIG