[Python-Dev] Accept just PEP-0426

[PJ Eby]

On Tue, Nov 20, 2012 at 11:49 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk>wrote:

> Also: what happens when a requirement is for setuptools (>= X.Y), but the
> distribute fork hasn't kept pace, and so only supports setuptools at a
> lower
> version than X.Y? I take it we're entirely comfortable with installing
> setuptools X.Y in that case? How would you ensure the right setuptools is
> always loaded, since presumably both are on sys.path?
>

Egg-based tools don't have any problem with this, since they set sys.path
to include the eggs needed for the running program.  Other tools will have
to tell the user and let them work it out, e.g. by using a different
virtualenv.

I personally don't think that forks claiming to "provide" something is
really a good thing to encourage; ISTM that saying a package *conflicts*
with another is more accurate, e.g. distribute Conflicts-Dist setuptools.
I also think distributions should say they are obsoleted, rather than
allowing other distributions to obsolete them.

That is, centralized packaging systems rely on a central authority to
resolve issues of who provides what and obsoletes what; there's an implicit
"x obsoletes y [by decree of semi-independent third-party z]".

However, in Python package metadata, it's "x obsoletes y [by decree of
x]".  IMO, this should be reversed to, "Y is obsoleted by x [by decree of
y]", and "installing Y will conflict with X [by decree of X]", so that in
each case the scope of authority for the statement is clear.

That is, in each case (conflict or obsolescence), the project's developers
are declaring under what conditions they will not be supporting an
installation.  In the case of obsolescence, the developer is saying, "this
is being phased out, you should use that other thing instead".  In the case
of forks, the developer is saying, "If you install both versions,
something's gonna break."

Note that installation conflict is a more conservative claim anyway: a
conflict between forked "foobar" packages is permanent, in the sense that
it doesn't matter what versions of both packages you're interested in: they
both want to install a foobar/__init__.py.  (Of course, installers can and
should detect that condition automatically, but not until they download the
package first.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121120/9952bd9c/attachment-0001.html>