[Python-Dev] PEP 396, Module Version Numbers

[Glenn Linderman]

On 4/9/2011 9:23 AM, Éric Araujo wrote:
> Hi,
>
> Le 06/04/2011 23:58, Glenn Linderman a écrit :
>> On 4/6/2011 7:26 AM, Nick Coghlan wrote:
>>> On Wed, Apr 6, 2011 at 6:22 AM, Glenn 
>>> Linderman<v+python at g.nevcal.com>  wrote:
>>>> With more standardization of versions, should the version module be 
>>>> promoted
>>>> to stdlib directly?
>>> When Tarek lands "packaging" (i.e. what distutils2 becomes in the
>>> Python 3.3 stdlib), the standardised version handling will come with
>>> it.
>>
>> I thought that might be part of the answer :)  But that, and below, seem
>> to indicate that use of "packaging" suddenly becomes a requirement for
>> all modules that want to include versions.  The packaging of "version"
>> inside a version of "packaging" implies more dependencies on a larger
>> body of code for a simple function.
> Not really.  Some parts of distutils2/packaging are standalone modules
> that are deliberately exposed publicly for third parties to use:
> version, metadata, markers, etc.  packaging.version is just the full
> name of the module implementing PEP 386.  (The first implementation,
> called verlib, has not been explicitly ended, nor the references in the
> PEP updated.)

Glad for the clarification here.  As long as packaging.version doesn't 
have dependencies on large amounts of code to be loaded from the rest of 
packaging, then I have no serious objection to that structure.

Although, writing "packaging.version" just now, it seems like the result 
could be perceived as the "packaging version" which might be distinct 
from the "real version" or "actual version" or "code version".  That's 
just a terminology thing that could be overcome with adequate documentation.

Then there is the question Nick raised about distributions that want to 
cut back on space, and provide alternate mechanisms than Python's 
packaging module to distribute code... producing the perception that 
they could avoid including packaging in their smallest distribution (but 
would probably package a packaging package using their packaging 
mechanism).  If that dropped packaging.version, it could be problematic 
for doing version checking in applications.  So distributions might have 
to split apart the packaging package.

Finally, if there are other competing historical packaging mechanisms, 
or new ones develop in the future, packaging packaging.version 
separately from the rest of packaging might avoid having different 
versions of version: when included a replacement system might think it 
needs to also replace that component for completeness.

So I still favor a top-level version module that isn't included in 
packaging, and implementation that doesn't depend on packaging.  But 
only at +0.


>> So, no support for single .py file modules, then?
> From packaging’s viewpoint, a project (something with a name and a
> version) is a directory with a setup.cfg file.  The directory can
> contain zero or more Python modules, Python packages, extension modules
> or data files.

 From packaging's viewpoint, there is nothing wrong with that.  But from 
a non-packaging viewpoint, a user of other distribution mechanisms 
wouldn't necessarily want to or need to create a setup.cfg file, nor be 
forced to write code to obtain __version__ by calling a packaging method 
to obtain it.  Not that the PEP as written currently requires that.

>> Caveat: I'm not 100% clear on when/how any of "distutils", "setuptools",
>> or "packaging" are invoked
>
> FTR: setuptools is a monkey-patching set of extensions to distutils:
> packaging is a full replacement of distutils.  packaging does not depend
> on distutils nor setuptools; it is a fork of distutils with some ideas
> and code taken from setuptools.

Thanks, but that part I actually knew from cecent discussion on this 
list.  What I'm not clear on is whether modules packaged by any of 
distutils, setuptools, or packaging, because of being packaged by them, 
wind up including  0%, 10%, 90%, or 100% of the code from distutils, 
setuptools, or packaging at runtime.  My favored percentage would be 0%, 
as I believe a packaging system should do its stuff at the time of 
making, distributing, and installing code, but should get out of the way 
of the runtime code, but I would find maybe 10% acceptable, if it was 
only one or two files to be searched for and included, to achieve 
significant benefits to the packaged code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110409/c1963e1b/attachment.html>