[Python-Dev] Keyword meanings [was: Accept just PEP-0426] (original) (raw)

PJ Eby pje at telecommunity.com
Thu Dec 6 01:34:41 CET 2012

On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft <donald.stufft at gmail.com> wrote:

Arguing over Obsoletes vs Renames is a massive bikeshedding argument.

And is entirely beside the point. The substantive question is whether it's Obsoletes or Obsoleted-By - i.e., which side is it declared on.

So it's a bad example. Hardly an argument against it.

Nobody has actually proposed a better one, outside of package renaming -- and that example featured an author who could just as easily have used an obsoleted-by field.

Will require support from PyPI but this ultimately isn't a big deal.

...and every PyPI clone. And of course the performance issues.

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.

Trusting their code is one thing; trusting whether they understood a PEP (and its interactions with various installation tools) well enough to not accidentally delete somebody else's code out of my system is another thing altogether.

OTOH, trusting an author to tell me (in an automated fashion), "hey, you should switch to this other thing as soon as you can" is a FAR smaller amount of required trust.

Arguing that because I have to trust one thing, means I must trust another, is a "Fallacy of Gray" argument.

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.

I didn't say it was invalid, I said:

"""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"""

These things are not equal. AFAIK, well-managed Linux distros do not allow random forkers to declare themselves the official successor to a defunct package, so any analogy between this use case in the Python world and the distro world is strained at best.

Unless you think there are no cases where two packages can conflict in more than what files are going to be installed

The rationale for that is laid out in the posts I linked.

then there are cases where it would be helpful

Please, present a real-life instance where it would have been helpful to you.

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.

One of the posts I linked presents an instance where it would have actually harmed things to specify it, and it's quite easy to see how the same problem would arise if used for non-file-related conflicts...

And the problem present is directly tied to the lack of a third-party Z who decides whether X and Y, as configured for release Q of distro P, "conflict".

This is not a problem that is solvable even in principle for an automated tool in the absence of party Z, which means that any such field's actual function is limited to a heads-up to a human user.

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.

I take it you're not familiar with PyPI's history of performance and scaling problems over the last several years, then. The statically cached "/simple" index was developed precisely to stop today's class of installation tools from killing the servers... and then mirroring PyPI was still required to scale. Any proposal that calls for encouraging tools to query a metadata field every time a package is installed (or even just downloaded) almost certainly needs to be vetted with the PyPI admin team.

More information about the Python-Dev mailing list