[Python-Dev] PEP 396, Module Version Numbers

[Nick Coghlan]

On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman <v+python at 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.

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia