[Python-Dev] Accept just PEP-0426
dholth at gmail.com
Tue Dec 4 02:44:52 CET 2012
On Tue, Nov 20, 2012 at 11:01 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Wed, Nov 21, 2012 at 1:20 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Wed, Nov 21, 2012 at 1:10 PM, PJ Eby <pje at telecommunity.com> wrote:
>>> Conversely, if you have already installed a package that says it
>>> "Obsoletes" another package, this does *not* tell you that the obsolete
>>> package shouldn't still be installed! A replacement project doesn't
>>> necessarily share the same API, and may exist in a different package
>>> namespace altogether.
>> Then that's a bug in the metadata of the project misusing "Obsoletes",
>> and should be reported as such. If the new package is not a drop-in
>> replacement, then it has no business claiming to obsolete the other package.
>> I think one of the big reasons this kind of use is rare in the Python
>> community is that project name changes are almost always accompanied by
>> *package* name changes, and as soon as you change the package name, you're
>> changing the public API, and thus it is no longer appropriate to use
>> Provides or Obsoletes, as the renamed project is no longer a drop-in
>> replacement for the original.
> I realised that my comments above are more about the appropriate use of
> "Provides", rather than "Obsoletes". For a practically useful "Obsoletes",
> I think I'm inclined to agree with you, as "Obsoleted-By" provides a way
> for a maintainer to explicitly declare that a project is no longer
> receiving updates, and users should migrate to the replacement project if
> they want to continue to receive fixes and improvements. The current
> version of "Obsoletes" is, as Daniel describes, really only useful as
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
A few more changes to try to address some of the confusion about
Requires-Dist: without re-designing the entire requirements system. PEP-426
was written only to add extras support to the format. The other changes,
re-writing much of the PEP, have been an unfortunate side-effect.
The file format's keys are case-insensitive.
The version number should be in PEP 386 form. There are too many
non-PEP-386 versions now and in the future to make it a must.
Distribution (requirement) names are noted as being distinct from ``import
x`` module names.
Parenthetical explanation has balanced parens.
"bundled" has been struck from the PEP.
diff -r 55c706023fa2 -r 026aebf2265d pep-0426.txt
--- a/pep-0426.txt Sun Nov 18 19:55:10 2012 +0200
+++ b/pep-0426.txt Mon Dec 03 20:36:13 2012 -0500
@@ -34,9 +34,9 @@
The syntax defined in this PEP is for use with Python distribution
metadata files. The file format is a simple UTF-8 encoded Key: value
-format with no maximum line length, followed by a blank line and an
-arbitrary payload. The keys are case-insensitive. It is parseable by
-the ``email`` module with an appropriate ``email.policy.Policy()``.
+format with case-insensitive keys and no maximum line length, followed by
+a blank line and an arbitrary payload. It is parseable by the ``email``
+module with an appropriate ``email.policy.Policy()``.
When ``metadata`` is a Unicode string,
```email.parser.Parser().parsestr(metadata)`` is a serviceable parser.
@@ -94,7 +94,7 @@
A string containing the distribution's version number. This
-field must be in the format specified in PEP 386.
+field should be in the format specified in PEP 386.
@@ -283,12 +283,13 @@
Each entry contains a string naming some other distutils
project required by this distribution.
-The format of a requirement string is identical to that of a
-distutils project name (e.g., as found in the ``Name:`` field.
-optionally followed by a version declaration within parentheses.
+The format of a requirement string is identical to that of a distribution
+name (e.g., as found in the ``Name:`` field) optionally followed by a
+version declaration within parentheses.
-The distutils project names should correspond to names as found
-on the `Python Package Index`_.
+The distribution names should correspond to names as found on the `Python
+Package Index`_; often the same as, but distinct from, the module names
+as accessed with ``import x``.
Version declarations must follow the rules described in
@@ -305,7 +306,8 @@
Like Requires-Dist, but names dependencies needed while the
distributions's distutils / packaging `setup.py` / `setup.cfg` is run.
-Commonly used to generate a manifest from version control.
+Commonly used to bring in extra compiler support or a package needed
+to generate a manifest from version control.
@@ -318,17 +320,19 @@
Provides-Dist (multiple use)
-Each entry contains a string naming a Distutils project which
-is contained within this distribution. This field *must* include
-the project identified in the ``Name`` field, followed by the
-version : Name (Version).
+Each entry contains a string naming a requirement that is satisfied by
+installing this distribution. This field *must* include the project
+identified in the ``Name`` field, optionally followed by the version:
A distribution may provide additional names, e.g. to indicate that
-multiple projects have been bundled together. For instance, source
-distributions of the ``ZODB`` project have historically included
-the ``transaction`` project, which is now available as a separate
-distribution. Installing such a source distribution satisfies
-requirements for both ``ZODB`` and ``transaction``.
+multiple projects have been merged into and replaced by a single
+distribution or to indicate that this project is a substitute for another.
+For instance distribute (a fork of setuptools) could ``Provides-Dist``
+setuptools to prevent the conflicting package from being downloaded and
+installed when distribute is already installed. A distribution that has
+been merged with another might ``Provides-Dist`` the obsolete name(s)
+to satisfy any projects that require the obsolete distribution's name.
A distribution may also provide a "virtual" project name, which does
not correspond to any separately-distributed project: such a name
@@ -359,10 +363,9 @@
Version declarations can be supplied. Version numbers must be in the
format specified in `Version Specifiers`_.
-The most common use of this field will be in case a project name
-changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0.
-When you install Torqued Python, the Gorgon distribution should be
+The most common use of this field will be in case a project name changes,
+e.g. Gorgon 2.3 gets renamed to Torqued Python 1.0. When you install
+Torqued Python, the Gorgon distribution should be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev