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

PJ Eby pje at telecommunity.com
Fri Dec 7 07:18:40 CET 2012

On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> 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?

Perhaps you could explain?  I'm not familiar with those projects.

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

But in each of these cases, the packages are being defined *with
reference to* some underlying vision of what the distro (or even "a
distro") is.  An Ubuntu PPA, if I understand correctly, is still
*building an Ubuntu system*.  Python packaging as a whole lacks such
frames of reference.  A forked distro is still a distro, and it's a
fork *of something*.  Rpmfusion is defining an enhanced Fedora, not
slinging random unrelated packages about.

If there's a distro analogy to PyPI, it seems to me that something
like RpmFind would be closer: it's just a free-for-all of packages,
with the user needing to decide for themselves whether installing
something from a foreign distro will or won't blow up their system.
(E.g., because their native distro and the foreign one use a different
"provides" taxonomy.)

RpmFind itself can't solve anybody's issues with conflicts or
obsoletes; all it can do is search the data that's there.

But unlike PyPI, RpmFind can at least tell you which vision of "a
distro" a particular package was intended for.  ;-)

> The ability for this class of fields to cause harm is not, to me,
> a compelling argument not to include them.

But it is absolutely not a compelling argument *to* include them, and
the actual arguments for them are pretty thin on the ground.

The real knockdown is that in the PyPI environment, there aren't any
automated use cases that don't produce collateral damage (outside of
advisories about Obsoleted-By projects).

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

AFAIK, there are only a handful of curated repositories: Scipy,
Enthought, and ActiveState come to mind.  These are essentially
"python distros", and they might certainly have reason to build policy
into their metadata.  I expect, however, that they would not want the
*package* authors declaring their own conflicts or obsolescence, so
I'm not sure how the metadata spec will help them.  Has anyone asked
for their input or experience?  It seems pointless to speculate on
what they might or might not need for curated distribution.  (I'm
pretty sure Enthought has their own install tools, not sure about the
other two.)

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

A peculiar phenomenon: every defense of these fields seems to refer
almost exclusively to how the problems could be fixed or why the
problems aren't that bad, rather than *how useful the fields would be*
in real-world scenarios.  In some cases, the argument for the fields'
safety actually runs *counter* to their usefulness, e.g., the fields
aren't that bad because we could make them have a limited function or
no function at all.  Isn't lack of usefulness generally considered an
argument for *not* including a feature?  ;-)

More information about the Python-Dev mailing list