[Python-Dev] Accept just PEP-0426

PJ Eby pje at telecommunity.com
Wed Nov 21 04:10:58 CET 2012

On Tue, Nov 20, 2012 at 6:43 PM, Daniel Holth <dholth at gmail.com> wrote:

> No. We trust the packages we install, including the way they decide to use
> the metadata. A bad package could delete all our files or cause dependency
> resolution to fail. Mostly they won't.

That's sort of beside the point.  The *only* use case which Obsoletes
provides over Obsoleted-By is that it allows third parties to unilaterally
advertise their forked project as a substitute for the original, and maybe
block users from switching back to the un-forked project -- regardless of
the status of the original project or the consent of the original project's

This use case, however, benefits nobody besides the forkers.  There are
many other legitimate channels by which the forkers can advertise
themselves as a replacement for their parent project, and no reason for the
installing end user to be bothered with the subject, except in case of a

For somebody obsoleting their own package, on the other hand, it's likely
well worth the effort to at least update their PyPI metadata to reflect the
change in status -- especially if this can be done through the web
interface.   It's likely they would wish to update their description as
well, to notify human beings of the change.

But here's the thing that kills "Obsoletes" dead in the first place as a
practical tool: unless installers use a PyPI search before installing
*every single project*, there is no way for them to realize that the
obsoleting package exists!

By contrast, if a package is "Obsoleted-By", then installing that package
(or declaring a dependency on it) provides an opportunity to inform the
user of the need to make a transition.  This can't be done with an
"Obsoletes" field.

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.

In short, "Obsoletes" is virtually *useless* as a machine-consumed metadata
field, because there is nothing you can actually do with it in a practical

I'm against adding more fields to the metadata which do not have a
specification for how they should be used in practice; the presence of such
fields has been a problem with most of the preceding metadata specs, IMO.

> I re-named a package once just because I did not like the name. I used
"Obsoletes" for that. It is documentation.

Note that "Obsoleted-By" would also serve that use case, and have the
additional benefit of being able to notify people who install new copies of
the replaced project.

(By the way Daniel, I'm sorry I didn't comment on this PEP sooner; I'd
forgotten about the previous PEP 345 rehashing in 2010, or rather, I just
sort of assumed that the results of that discussion had been incorporated
into the newer PEP, and didn't notice the reappearance of the noise fields
until your call for approval just now.  Sorry!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121120/51defd4e/attachment-0001.html>

More information about the Python-Dev mailing list