On Tue, Apr 13, 2010 at 5:10 PM, Tres Seaver <email address hidden> wrote:
> AFAIK, we have 3 places to put the version number without duplication:
>
> - in setup.py (where it has to be passed to setup(). pkg_resources consumes
> this value indirectly through the PKG-INFO file generated during installation.
>
> - in an attribute of a module (which one, please? Defend your choice.
> ;)
>
> - In a data file in the package (something like the Zope2 product convention of
> 'version.txt').
I would put it in a text file in the package. I would have the
__init__ of the package load this into the __version__ attribute for
instrospection by run-time code. (AFAIK, __version__ is still a Python
standard.)
I would have the setup.py read the file by constructing a relative
path. (I don't want setup.py to try importing the package.)
> Note that without setuptools / distribute installed, we are already
> running in degraded mode (hard wiring filename globs for package data,
> no C optimizations, no documentation generation, wonky namespace package
> support, etc.). Do we really expect to deliver this feature in that
> case?
>
> The 'pkg_resources' solution is uniform across *all* installed packages
> (even stdlib modules in 2.7). I would vote for sticking with it as the
> blessed solution to this need.
If Guido blesses it, I'll go along. :)
I don't like the idea of being dependent pn pkg_resoures for the
feature. My opinion would change if the API used to get the version
was part of the standard library.
I don't feel strongly about this, but would be inclined to try to do
something simple.
On Tue, Apr 13, 2010 at 5:10 PM, Tres Seaver <email address hidden> wrote:
> AFAIK, we have 3 places to put the version number without duplication:
>
> - in setup.py (where it has to be passed to setup(). pkg_resources consumes
> this value indirectly through the PKG-INFO file generated during installation.
>
> - in an attribute of a module (which one, please? Defend your choice.
> ;)
>
> - In a data file in the package (something like the Zope2 product convention of
> 'version.txt').
I would put it in a text file in the package. I would have the
__init__ of the package load this into the __version__ attribute for
instrospection by run-time code. (AFAIK, __version__ is still a Python
standard.)
I would have the setup.py read the file by constructing a relative
path. (I don't want setup.py to try importing the package.)
> Note that without setuptools / distribute installed, we are already
> running in degraded mode (hard wiring filename globs for package data,
> no C optimizations, no documentation generation, wonky namespace package
> support, etc.). Do we really expect to deliver this feature in that
> case?
>
> The 'pkg_resources' solution is uniform across *all* installed packages
> (even stdlib modules in 2.7). I would vote for sticking with it as the
> blessed solution to this need.
If Guido blesses it, I'll go along. :)
I don't like the idea of being dependent pn pkg_resoures for the
feature. My opinion would change if the API used to get the version
was part of the standard library.
I don't feel strongly about this, but would be inclined to try to do
something simple.
Jim
--
Jim Fulton