On Wednesday, December 5, 2012 at 4:10 PM, PJ Eby wrote: > 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.
Arguing over Obsoletes vs Renames is a massive bikeshedding argument. > 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. > > So it's a bad example. Hardly an argument against it. > 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. > > Will require support from PyPI but this ultimately isn't a big deal. > > 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! > > If you're installing B you've prescribed trust to that author. If you don't trust the author then why are you installing (and then executing) code they wrote. > > 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.) > > Very convenient to declare that one of the major use cases for Obsoletes over Obsoleted-By is not valid because of your own personal opinions. Like I said above, if you're installing a package that someone has uploaded you've implicitly granted them trust. There is far worse things that a bad Python citizen can do during, and after and install that what is allowed by Obsoletes. > > > > 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.) > > I don't think Conflicts is something that every single package is going to require. As you said the tools themselves are going to handle the obvious cases for the bulk of situations. Unless you think there are no cases where two packages can conflict in more than what files are going to be installed then there are cases where it would be helpful and merely having the ability to use it when it is the best tool for the job isn't going to cause any great issue. > > While it's certainly desirable to not invent wheels, it's important to > understand that the Python community does not work the same way as a > Linux distribution. We are not a single organization shipping a > fully-functional and configured machine, we are hundreds of individual > authors shipping our own stuff. Conflict resolution and package > replacement (and even deciding what it is that things "provide" or > "require") are primarily *human* processes, not technical ones. > Relationship and support "contracts", IOW, rather than software > contracts. > > End systems often times do not have a singular organization controlling every package in their system. The best example is Ubuntu and their PPA's. > > Now, if the will of the community is to turn PyPI into a distro-style > repository, that's fine... but even if you completely ignore the human > issues, there are still technical ones. Generally, distro-style > repositories work by downloading the full metadata set (or at least an > index) to a user's machine. And that's the sort of architecture you'd > need in order for these type of fields to be technically feasible > (e.g., doing an index search for Obsoletes), without grinding the PyPI > servers into dust. This is insane. A fairly simple database query is going to "grind the PyPI servers into dust"? You're going to need to back up this FUD or please refrain from spouting it.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
