[Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

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.