Jeff Rush wrote: > A. Cavallo wrote: > >>> No, I would say “too much” here is importing a module not guaranteed to >>> be installed, for creating something as simple as a version. I'd prefer >>> the above to be:: >>> >>> $ cat _version.py >>> # This is an auto-generated file. Use magicbean to update. >>> version = "0.9.33" >>> $ >>> >> Or my preferred way: >> $cat foobar/__init__.py >> __version__ = "0.9.33" >> >> and import foobar should not trigger code execution anyway IMHO so >> $ python -c 'import foobar; print foobar.__version__' >> 0.9.33 >> > > That doesn't work in all cases. Your example is of an external query of the > version of an installed module. You also need to query the version -before- > it is installed (during the packaging phase) on sys.path, and also from > -within- the foobar module itself. Your code does not handle those cases. An > attempt to 'import foobar; print foobar.__version__' from a setup.py inside > foobar won't find foobar. >
That's my experience as well. I am a bit delighted to see that other people struggled on this, I felt very stupid the first time I tried to setup this consistently without success. My current approach is to set up the version in setup.py, but to always generated a trivial version.py within the package (for the installed version). The setup.py version is used by paver, the installed version is used by the sphinx build inside a bootstrapped environment. I think the situation where you want to build documentation at the same time as the software happens relatively often, I would be glad to hear of a better alternative. cheers, David _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
