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