[Distutils] [Python-Dev] Accept just PEP-0426

Daniel Holth 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
> documentation.
>
> Cheers,
> Nick.
>
> --
> 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.

 Example::

@@ -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
 `Version Specifiers`_
@@ -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.

 Examples::

@@ -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:
+Name (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
-removed.
+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.

 Examples::
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20121203/35430668/attachment.html>


More information about the Distutils-SIG mailing list