[Python-Dev] PEP 396, Module Version Numbers

[Glenn Linderman]

On 4/6/2011 11:53 PM, Nick Coghlan wrote:
> 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)

I knew that packaging replaced those others, but was unaware that those 
were the only two methods used on PyPI.  Not that I'd heard of or 
experienced any others from that source, but there are many packages there.


>> 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.

This sounds more practical; if I recall prior discussions correctly, 
pkgutil reads a standard set of metadata data packaging systems should 
provide, and version would seem to be part of that, more so than of 
packaging itself... seems things would have a better (smaller at 
runtime) dependency tree that way, from what I understand about it.

> 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

Thanks Nick, for the info in this thread.   This is mostly a thank you 
note for helping me understand better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110407/781fc3bb/attachment.html>