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+pyt...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
