__author__

Peter L Hansen peter at engcorp.com
Fri Oct 1 21:35:04 CEST 2004


Mike C. Fletcher wrote:
> Peter L Hansen wrote:
>> (I've tended to use VERSION, I believe, but I'm moving towards
>> using a build.xml file containing a variety of meta-information
>> for the entire package, rather than an embedded constant.)
> 
> Ah yes, much easier to work with ;) :
> 
>    import package
>    if [int(i) for i in package.__version__.split('.')[:2]] > [2,3]:
>       blah()
> 
> versus:
> 
>    import package
>    tag = findVersionTag(parseXMLFile(findXMLFile( package )))
>    if (findMajorVersion(tag),findMinorVersion(tag)) > (2,3):
>       blah()
> 
> Just teasing, you know I believe that XML is the solution to all 
> problems in the universe which can't be addressed *directly* with Java 
> ;) .  As long as you're exposing APIs that mean client libraries never 
> have to do the actual finding and parsing of the XML file, having your 
> "get version" API integrated into your package-management code can be 
> very useful for keeping them in sync.
> 
> Still, __version__ is a pretty simple API...

Actually, the XML is invisible to anything outside the application,
while simplifying a variety of things relating to the rest of my
infrastructure, including automatic documentation generation,
testing framework, packaging, and revision control.

At the top of the app/package, I have a "from buildutils import build"
call, and then I can do "build.version", or "build.exename", or
whatever...  if I care to support folks like you who might want to
do "xxx.__version__" I guess I should do a "__version__ = build.version"
at the top of the module...  hadn't thought of that.

Basically, the stuff is read at run-time, so _you_ wouldn't
be able to tell the difference, but I have the information
maintained externally instead of being coupled to the Python
code and inaccessible to, say, InnoSetup or py2exe or my own
utilities which might not or have the means to import the
module.

And as you surmised, this is largely about keeping things in
sync and avoiding duplication.  In the most recent thing that
uses this, I need pieces of the build.xml content in all the
places mentioned above, meaning I've finally achieved my goal
of removing about five different instances of duplication and
my release process can be completely automated, provided I've
remembered to update the version number at all...

-Peter



More information about the Python-list mailing list