[Python-Dev] PEP 396, Module Version Numbers (original) (raw)

Éric Araujo merwok at netwok.org
Sat Apr 9 18:23:34 CEST 2011

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

More information about the Python-Dev mailing list