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.