On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman <v+python@g.nevcal.com> wrote:
__version__ = "7.9.7xxxx" # replaced by "packaging"
If you don't upload your module to PyPI, then you can do whatever you
want with your versioning info. If you *do* upload it to PyPI, then
part of doing so properly is to package it so that your metadata is
where other utilities expect it to be. At that point, you can move the
version info over to setup.cfg and add the code into the module to
read it from the metadata store.
The PEP doesn't mention PyPI, and at present none of the modules there use
"packaging" :)
They all use distutils (or setuptools or distutils2) though, which is
what packaging replaces.
(Sorry for not making that clear - it's easy to forget which aspects
of these issues aren't common knowledge as yet)
So it wasn't obvious to me that the PEP applies only to
PyPI, and I have used modules that were not available from PyPI yet were
still distributed and packaged somehow (not using "packaging" clearly).
packaging is the successor to the current distutils package.
Distribution via PyPI is the main reason to bother with creating a
correctly structured package - for internal distribution, people use
all sorts of ad hoc schemes (often just the packaging systems of their
internal target platforms). I'll grant that some people do use
properly structured packages for purely internal use, but I'd also be
willing to bet that they're the exception rather than the rule.
What I would like to see the PEP say is that if you don't *have* a
setup.cfg file, then go ahead and embed the version directly in your
Python source file. If you *do* have one, then put the version there
and retrieve it with "pkgutil" if you want to provide a __version__
attribute.
Barry is welcome to make a feature request to allow that dependency to
go the other way, with the packaging system reading the version number
out of the source file, but such a suggestion doesn't belong in an
Informational PEP. If such a feature is ever accepted, then the
recommendation in the PEP could be updated.
While there has been much effort (discussion by many) to make "packaging"
useful to many, and that is probably a good thing, I still wonder why a
packaging system should be loaded into applications when all the code has
already been installed. Or is the runtime of "packaging" packaged so that
only a small amount of code has to be loaded to obtain "version" and
"__version__"? I don't recall that being discussed on this list, but maybe
it has been on more focused lists, sorry for my ignorance... but I also read
about embedded people complaining about how many files Python opens at start
up, and see no need for a full packaging system to be loaded, just to do
version checking.
pkgutil will be able to read the metadata - it is a top level standard
library module, *not* a submodule of distutils/packaging.
It may make sense for the version parsing support to be in pkgutil as
well, since PEP 345 calls for it to be stored as a string in the
package metadata, but it needs to be converted with NormalizedVersion
to be safe to use in arbitrary version range checks. That's Tarek's
call as to whether to provide it that way, or as a submodule of
packaging. As you say, the fact that distutils/packaging are usually
first on the chopping block when distros are looking to save space is
a strong point in favour of having that particular functionality
somewhere else.