<div class="gmail_quote">On Tue, Nov 20, 2012 at 6:43 PM, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br>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 maintainer.<br>
<br>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 conflict.<br>
<br>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.<br>
<br>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!<br>
<br>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.<br>
<br>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.<br>
<br>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 installer.<br><br>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.<br>
<br><br>> I re-named a package once just because I did not like the name. I used "Obsoletes" for that. It is documentation.<br><br>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.<br>
<br>(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!)<br>
</div></div><br>