[Python-Dev] Keyword meanings [was: Accept just PEP-0426]

Daniel Holth dholth at gmail.com
Wed Dec 5 23:30:37 CET 2012

On Wed, Dec 5, 2012 at 4:10 PM, PJ Eby <pje at telecommunity.com> wrote:

> On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft <donald.stufft at gmail.com>
> wrote:
> > There's nothing preventing an installer from, during it's attempt to
> > install B, see it Obsoletes A, looking at what depends on A and
> > warning the user what is going to happen and prompt it.
> Unless the user wrote those things that depend on A, they aren't going
> to be in a position to do anything about it.  (Contrast with a distro,
> where dependencies are indirect - the other package will depend on an
> abstraction provided by both A and B, rather than directly depending
> on A *or* B.)
> (Also note that all the user knows at this point is that the author of
> B *claims* to obsolete A, not that the authority managing the
> repository as a whole has decreed B to obsolete A.)
> > You can automatically uninstall A from B in an automatic dependency
> management system
> My point is that this can only work if the "obsoleting" is effectively
> just a rename, in which case the field should be "renames", or better
> still, "renamed-to" on the originating package.
> As I've mentioned repeatedly, Obsoleted-By handles more use cases than
> Obsoletes, and has at least one practical automated use case
> (notifying a developer that their project is depending on something
> that's obsolete).
> Also, the example given as a use case in the PEP (Gorgon to Torqued)
> is not just wrong, it's *actively misleading*.  Gorgon and Torqued are
> transparent renames of Medusa and Twisted, which do not share a common
> API and thus cannot be used as the subject of any automated processing
> (in the case of Obsoletes) without doing some kind of PyPI metadata
> search for every package installed every time a package is installed.
> > I think Obsoletes as is an alright bit of information.
> 1. It cannot be used to prevent the installation of an obsolete
> package without a PyPI metadata search, since you must examine every
> *other* package on PyPI to find out whether some package obsoletes the
> one you're trying to install.
> 2. Unlike RPM, where metadata is provided by a trusted third party,
> Obsoletes can be specified by any random forker (no pun intended),
> which makes this information a mere advertisement... and an
> advertisement to the wrong audience at that, because they must have
> *already* found B in order to discover that it replaces A!
> 3. Nobody has yet supplied a use case where Obsoletes would not be
> strictly improved upon by Obsoleted-By.  (Note that "the author of
> package X no longer maintains it" does not equal "package Y is
> entitled to name itself the successor and enforce this upon all users"
> -- this can work in RPM only because it is a third party Z who
> declares Y the successor to X, and there is no such party Z in the
> Python world.)
> > I don't see this in this thread, could you link it again?
> http://mail.python.org/pipermail/catalog-sig/2010-October/003368.html
> http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html
> These posts also address why a "Conflicts" field is *also* unlikely to
> be particularly useful in practice, in part for reasons that relate to
> differences between RPM-land and Python-land.  (For example, RPMs can
> conflict over things besides files, due to runtime and configuration
> issues that are out-of-scope for a Python installer tool.)
> While it's certainly desirable to not invent wheels, it's important to

My desire is to invent the useful "wheel" binary package format in a
reasonable and limited amount of time by making changes to Metadata 1.2 and
implementing the new metadata format and wheel in distribute and pip. Help
me out by allowing useless but un-changed fields to remain in this version
of the PEP. I am done with the PEP and submit that it is not worse than its

I can participate in a discussion about any of the following:
Summary of Differences From PEP 345<http://www.python.org/dev/peps/pep-0345>

   - Metadata-Version is now 1.3.
   - Values are now expected to be UTF-8.
   - A payload (containing the description) may appear after the headers.
   - Added extra to environment markers.
   - Most fields are now optional.
   - Changed fields:
      - Description
      - Project-URL
      - Requires-Dist
   - Added fields:
      - Extension
      - Provides-Extra
      - Setup-Requires-Dist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121205/e3a8e27c/attachment.html>

More information about the Python-Dev mailing list