<div><span style="color: rgb(160, 160, 168); ">On Wednesday, December 5, 2012 at 4:10 PM, PJ Eby wrote:</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div>My point is that this can only work if the "obsoleting" is effectively</div><div>just a rename, in which case the field should be "renames", or better</div><div>still, "renamed-to" on the originating package.</div></span></blockquote><div>Arguing over Obsoletes vs Renames is a massive bikeshedding argument. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div>As I've mentioned repeatedly, Obsoleted-By handles more use cases than</div><div>Obsoletes, and has at least one practical automated use case</div><div>(notifying a developer that their project is depending on something</div><div>that's obsolete).</div><div><br></div><div>Also, the example given as a use case in the PEP (Gorgon to Torqued)</div><div>is not just wrong, it's *actively misleading*. Gorgon and Torqued are</div><div>transparent renames of Medusa and Twisted, which do not share a common</div><div>API and thus cannot be used as the subject of any automated processing</div><div>(in the case of Obsoletes) without doing some kind of PyPI metadata</div><div>search for every package installed every time a package is installed.</div></div></div></span></blockquote><div>So it's a bad example. Hardly an argument against it.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div>1. It cannot be used to prevent the installation of an obsolete</div><div>package without a PyPI metadata search, since you must examine every</div><div>*other* package on PyPI to find out whether some package obsoletes the</div><div>one you're trying to install.</div></div></div></span></blockquote><div>Will require support from PyPI but this ultimately isn't a big deal. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>2. Unlike RPM, where metadata is provided by a trusted third party,</div><div>Obsoletes can be specified by any random forker (no pun intended),</div><div>which makes this information a mere advertisement... and an</div><div>advertisement to the wrong audience at that, because they must have</div><div>*already* found B in order to discover that it replaces A!</div></div></div></span></blockquote><div>If you're installing B you've prescribed trust to that author. If you don't</div><div>trust the author then why are you installing (and then executing) code</div><div>they wrote. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>3. Nobody has yet supplied a use case where Obsoletes would not be</div><div>strictly improved upon by Obsoleted-By. (Note that "the author of</div><div>package X no longer maintains it" does not equal "package Y is</div><div>entitled to name itself the successor and enforce this upon all users"</div><div>-- this can work in RPM only because it is a third party Z who</div><div>declares Y the successor to X, and there is no such party Z in the</div><div>Python world.)</div></div></div></span></blockquote><div>Very convenient to declare that one of the major use cases for</div><div>Obsoletes over Obsoleted-By is not valid because of your own</div><div>personal opinions. Like I said above, if you're installing a package</div><div>that someone has uploaded you've implicitly granted them trust. There</div><div>is far worse things that a bad Python citizen can do during, and after</div><div>and install that what is allowed by Obsoletes.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div><br></div><blockquote type="cite"><div>I don't see this in this thread, could you link it again?</div></blockquote><div><br></div><div><a href="http://mail.python.org/pipermail/catalog-sig/2010-October/003368.html">http://mail.python.org/pipermail/catalog-sig/2010-October/003368.html</a></div><div><a href="http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html">http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html</a></div><div><br></div><div>These posts also address why a "Conflicts" field is *also* unlikely to</div><div>be particularly useful in practice, in part for reasons that relate to</div><div>differences between RPM-land and Python-land. (For example, RPMs can</div><div>conflict over things besides files, due to runtime and configuration</div><div>issues that are out-of-scope for a Python installer tool.)</div></div></div></span></blockquote><div>I don't think Conflicts is something that every single package is going</div><div>to require. As you said the tools themselves are going to handle the</div><div>obvious cases for the bulk of situations. Unless you think there are</div><div>no cases where two packages can conflict in more than what files</div><div>are going to be installed then there are cases where it would be helpful</div><div>and merely having the ability to use it when it is the best tool for the job</div><div>isn't going to cause any great issue. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>While it's certainly desirable to not invent wheels, it's important to</div><div>understand that the Python community does not work the same way as a</div><div>Linux distribution. We are not a single organization shipping a</div><div>fully-functional and configured machine, we are hundreds of individual</div><div>authors shipping our own stuff. Conflict resolution and package</div><div>replacement (and even deciding what it is that things "provide" or</div><div>"require") are primarily *human* processes, not technical ones.</div><div>Relationship and support "contracts", IOW, rather than software</div><div>contracts.</div></div></div></span></blockquote><div>End systems often times do not have a singular organization controlling</div><div>every package in their system. The best example is Ubuntu and their PPA's. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><br></div><div>Now, if the will of the community is to turn PyPI into a distro-style</div><div>repository, that's fine... but even if you completely ignore the human</div><div>issues, there are still technical ones. Generally, distro-style</div><div>repositories work by downloading the full metadata set (or at least an</div><div>index) to a user's machine. And that's the sort of architecture you'd</div><div>need in order for these type of fields to be technically feasible</div><div>(e.g., doing an index search for Obsoletes), without grinding the PyPI</div><div>servers into dust.</div></span></blockquote><div>This is insane. A fairly simple database query is going to "grind the PyPI</div><div>servers into dust"? You're going to need to back up this FUD or please</div><div>refrain from spouting it.</div>
<div>
<br>
</div>