On Tue, Nov 20, 2012 at 11:01 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Wed, Nov 21, 2012 at 1:20 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Wed, Nov 21, 2012 at 1:10 PM, PJ Eby <pje@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@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::