On 11/20/2012 12:46 PM, PJ Eby wrote:
On Tue, Nov 20, 2012 at 11:49 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk
<mailto:vinay_sa...@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.
Obsolete distributions won't say they are obsoleted, unless they receive
further maintenance. However, if the distribution is obsolete because
the maintainer has lost interest, they won't receive further maintenance.
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.)
_______________________________________________
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
