[Distutils] easy_install: --tag-svn-revision

Ian Bicking ianb at colorstudy.com
Thu Aug 11 00:23:56 CEST 2005


Phillip J. Eby wrote:
> At 03:08 PM 8/10/2005 -0500, Ian Bicking wrote:
> 
>> I don't think --tag-svn-revision should apply to dependencies.  Maybe 
>> it should even be an error if you try to use it on a package that 
>> isn't a subversion repository.
> 
> 
> On the other hand, I don't suppose it would hurt to just ignore it if it 
> doesn't apply.  I'm uneasy about dependencies, of course, but then 
> again, where's the harm there either?

The harm in adding the revision there?  Not that great, I guess.  It's 
kind of a stop-gap measure either way; modifying setup.cfg in the 
repository itself seems like the right way to handle the versions.

> The biggest potential harm of --tag-svn-revision is that it makes things 
> a *higher* revision number by default.  I.e. "1.2-r27" is a higher 
> version number than "1.2", so if you're using a strategy where you use 
> the *next* version number in your svn version of setup.py, then you're 
> going to have problems when the official version is released.  In other 
> words, if svn's setup.py says "1.2" is the current version, but that's 
> the version you're *developing* (as opposed to enhancing), then the 
> numbering works out wrong.

True.  I'm never sure what version I should use in a repository.  The 
next version isn't true, the last version isn't true. 
"next_version-DEV" is probably right, I guess.

Nevertheless, it's still possible to use --tag-build to fix version 
numbers in case of problems.  It's not very sticky, though; it'd be easy 
to forget how it should be properly applied, or how it was applied in 
the past.  The ability to list packages would help resolve what problems 
do occur; especially listed in the order pkg_resources thinks they go 
in, showing which one is active, etc.

The main reason for stuff like this is to make it possible to use 
easy_install.py for an entire deployment without requiring all the 
software to be written with setuptools in mind.  So even if it is 
suboptimal, it's still of some use.

Another option might be something like "python -m setuptools setup.py" 
which would run setup.py with setuptools.  But then this is really just 
what easy_install does, except with a larger command set (egg_info in 
particular).  "easy_install.py --setup checkout-dir/ 
setuptools_commands..." perhaps?

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Distutils-SIG mailing list