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

Toshio Kuratomi a.badger at gmail.com
Fri Dec 7 18:01:34 CET 2012

On Fri, Dec 07, 2012 at 01🔞40AM -0500, PJ Eby wrote:

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.

pexepect was last released in 2008. Upstream went silent with unanswered bugs in its tracker and no mailing list. A fork of pexpect was created that addressed the issue of unicode type in python2, a python3 port, and has slowly evolvd since then.

I see that the original upstream has made some commits to their source repository since the fork was created although there has still been no new release.

> 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. Uhm.... that's both true and false as any complex system is. rpm and deb are just packaging formats. So:

*) Not all packages built build on top of that system. There are rpm packages provided by upstreams that users attempt (to greater and lesser degrees of success) to install on SuSE, RHEL, Fedora, Mandriva, etc. There are debs built for Ubuntu that people attempt to install onto Debian.

*) PPAs and rpmfusion may both build on top of an existing system but they can change the underlying structure, replacing components that other pieces of the base system depend on. You talk about the setuptools and distribute problem on pypi.... there's absolutley nothing that prevents someone from building a PPA or a package in a third-party rpm repository that packages a setuptools that Obsoletes: distribute or a distribute package that Obsoletes: setuptools.

> 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? ;-) If you constantly forget why the fields are useful, then I suppose you'll always believe that :-)

-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/20121207/c37c3796/attachment.pgp>

More information about the Python-Dev mailing list