[Distutils] automating __version__' ing issues

[Phillip J. Eby]

At 11:45 AM 5/13/2007 -0400, Alexander Michael wrote:
>SVN does support keywords, but you need to turn-on keyword
>interpolation (see the SVN documentation describing properties for how
>to do this), but I don't think you'll need this functionality.
>Development release suffixes can be added with setuptools
>(<http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-releases-using-subversion>).
>  When using this technique, the setup.py version string must be the
>*next* version (the one under development that is typically your SVN
>Trunk).

It only has to be the next version if you're using a prerelease 
suffix like "dev".  For example "1.2-r5499" is SVN revision 5499 of 
an already-released version 1.2.  If you *haven't* released 1.2, you 
want to call it '1.2.dev-r5499' instead, which compares less than '1.2', e.g.:

 >>> from pkg_resources import parse_version as pv
 >>> pv('1.2') > pv('1.2dev')
True
 >>> pv('1.2-r5499') > pv('1.2')
True
 >>> pv('1.2-r5499') > pv('1.2dev-r5499')
True


>Here's the rub-- it must be in setup.py and you probably want
>to give your package access to it so that it can be reported. It
>appears that the current idiom for solving this dilemma is to but a
>release.py or version.py file in your package, which is sucked up into
>the setup.py file with execfile (see
><http://kid-templating.org/trac/browser/trunk/setup.py> for an
>example). You then manually maintain the version number in one place
>(the release.py file).

Yep, this is what most people do.  I actually use a PEAK tool called 
"version" (peak.tools.version) which maintains a data file with the 
version, and does targeted search-and-replace operations on the files 
listed in a configuration file.  This is a lot easier when you have 
documentation files that also need version information updated, and 
it also avoids the execfile pain.