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

[Phillip J. Eby]

At 05:23 PM 8/10/2005 -0500, Ian Bicking wrote:
>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.

Not quite; the '-' means that 'DEV' is a patchlevel, and goes right back to 
the "later version" problem.  You need something like '1.2dev' or '1.2pre' 
to make it a pre-release version.


>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.

Personally, I create aliases for different build patterns, and just run 
those aliases.  "setup.py alias" is your friend.  :)


>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?

Try Ryan's buildutils (just "easy_install buildutils").  His 'pbu' script 
runs setup.py with setuptools installed, and as of the CVS version, 
setuptools now embeds itself deep into the distutils so that even a script 
that doesn't use setuptools should end up using setuptools anyway, at least 
enough to enable the full command set.

Whether that *actually* works with the current versions of buildutils and 
setuptools, I couldn't say.  I don't know if buildutils has been updated to 
work with the entry point stuff for distutils extensions yet, although even 
if it hasn't it might still work anyway.