On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman email@example.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.
That said, I've seen people have problems because a Python 2.6 redistributor decided "contextlib" wasn't important and left it out, so YMMV regardless of where the code ends up.