"Alexander Michael" <[EMAIL PROTECTED]> 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
