<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
<div class="moz-cite-prefix">On 11/20/2012 12:46 PM, PJ Eby wrote:<br>
</div>
<blockquote
cite="mid:CALeMXf7EtrORHEq8GYQ0nXo52n5b2L0-KQRJAgJSiX101egiCw@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Tue, Nov 20, 2012 at 11:49 AM, Vinay
Sajip <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:vinay_sajip@yahoo.co.uk" target="_blank">vinay_sajip@yahoo.co.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Also: what happens when a requirement is for setuptools (>=
X.Y), but the<br>
distribute fork hasn't kept pace, and so only supports
setuptools at a lower<br>
version than X.Y? I take it we're entirely comfortable with
installing<br>
setuptools X.Y in that case? How would you ensure the right
setuptools is<br>
always loaded, since presumably both are on sys.path?<br>
</blockquote>
<div><br>
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.<br>
<br>
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.<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CALeMXf7EtrORHEq8GYQ0nXo52n5b2L0-KQRJAgJSiX101egiCw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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]".<br>
<br>
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.<br>
<br>
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."<br>
<br>
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.)<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>