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

[Toshio Kuratomi]

On Fri, Dec 07, 2012 at 01:18: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>