[Python-Dev] PEP 396, Module Version Numbers

[Éric Araujo]

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

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

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

 Regards