On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi <a.bad...@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.stu...@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? ;-) _______________________________________________ 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
