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

Toshio Kuratomi a.badger at gmail.com
Thu Dec 6 07:49:25 CET 2012

On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:

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

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. How about pexpect and pextpect-u as a better example?

> 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. Note that although well-managed Linux distros attempt to control random forking internally, the distro package managers don't prevent people from installing from third parties. So Ubuntu PPAs, upstreams that provide their own rpms/debs, and major third party repos (for instance, rpmfusion as an add-on repo to Fedora) all have and sometimes (mis)use the ability to Obsolete packages in the base repository.

So Donald isn't stretching the relationship quite as far as you make it out. The ecosystem of packages for a distro carries uncontrolled packages just as much as pypi.

> 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. And the same for Provides. (ie: latest foo is 0.6c; bar Provides: foo-0.6d. an automated tool that finds both foo and bar in its dep tree can choose to install bar and not foo.)

The ability for this class of fields to cause harm is not, to me, a compelling argument not to include them. It could be an argument to explicitly tell implementers of install tools that they all have caveats when used with pypi and similar unpoliced community package repositories. The install tools can then choose how they wish to deal with those caveats. Some example strategies: choose to prompt the user as to which to install, choose to always treat the fields as human-informational only, mark some repositories as being trusted to contain packages where these fields are active and other repositories where the fields are ignored.

-Toshio

-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20121205/cdb8ac46/attachment.pgp>

More information about the Python-Dev mailing list