[Python-Dev] PEP 396, Module Version Numbers

Nick Coghlan ncoghlan at gmail.com
Thu Apr 7 06:08:21 CEST 2011


On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> Perhaps a different technique would be that if packaging is in use, that it
> could somehow inject the version from setup.cfg into the module, either by
> tweaking the source as it gets packaged, or installed, or tweaking the
> module as/after it gets loaded (the latter still required some runtime
> dependency on code from the packaging system).  A line like the following in
> some designated-to-"packaging" source file could be replaced during
> packaging:
>
> __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 guidelines in 396 really only apply to distributed packages, so it
doesn't make sense to obfuscate by catering to esoteric use cases. If
prviate modules don't work with the standard tools, who is going to
care? The module author clearly doesn't, and they aren't distributing
it to anyone else. Once they *do* start distributing it, then their
new users will help bring them into line. Having the recommended
practice clearly documented just makes it easier for those users to
point new module distributors in the right direction.

(Also, tsk, tsk, Barry for including Standards track proposals in an
Informational PEP!)

Cheers,
Nick.

P.S. A nice coincidental progression: PEP 376, 386 and 396 are all
related to versioning and package metadata

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


More information about the Python-Dev mailing list