[Distutils] automating __version__' ing issues

[Alexander Schmolck]

"Alexander Michael" <lxander.m at gmail.com> writes:

> SVN does support keywords, but you need to turn-on keyword
> interpolation (see the SVN documentation describing properties for how
> to do this)

I know, but the svn $Revision$ keyword doesn't have the semantics I've
described (that's what I meant with 'working' -- I don't think the implemented
behavior is what one would typically desire; to get a subset of what I
described in an awkward and roll-you-own fashion one can muck around with the
``svnversion`` command, but I'd rather use some off-the-shelf mucking around).

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

Yuck. I don't think this does what I want either -- how is the development
release suffix mean to get into release.py? What kid does seems broken -- it
just uses the $Rev$ keyword, but's the local file revision, not that of the
project as a whole.

<http://kid-templating.org/trac/browser/trunk/kid/release.py>

> You then manually maintain the version number in one place
> (the release.py file).

I'm happy to manually maintain the version number (i.e. "1.1"), but not the
release number for development releases (i.e. the .dev bit in "1.1.dev43").

> Also note that it appears the current trend is to keep __init__.py
> files empty (required if you ever want to create a setuptools
> namespace package) and create an api.py file with convenient exports.
> This is done to avoid running into issues with circular references.

I've heard about this new trend to use mypackage.api before, but I didn't get
a particularly good rationale -- I can see that this might can be helpful if
you want to be able to import ``mypackage.bar`` without being forced to import
the the stuff in ``mypackage``, but that would only seem to apply to a few big
projects with independent components -- how does it help with circular
references?

> I would be tempted to but version information my __init__.py file (and only
> version information), but this will breakdown if the package ever grows to
> become a namespace package. Perhaps avoiding this simplification, however,
> is over future-proofing.

I dont see mlabwrap becoming a namespace package. If that really happens I'll
be happy to force users to change their import statements for having
experienced the convenience of not having to type another 4 characters in the
past.

'as