<div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 20, 2012 at 9:35 AM, Vinay Sajip <span dir="ltr"><<a 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">
<div class="im">Daniel Holth <dholth <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
<br>
> Mostly it seems a bit silly to have so much conversations about parts of the<br>
> pep that remain unchanged from previously accepted versions...<br>
<br>
</div>I don't agree with the suggestion that we shouldn't discuss it because it was<br>
accepted in a previous version. Perhaps it didn't receive the right scrutiny at<br>
that time, but since it hasn't been implemented, it's reasonable to discuss it.<br>
<br>
ISTM that implementing it as suggested in the PEP can lead to certain problems,<br>
since it is a multi-valued field. If it is left in, then something should be<br>
said in the PEP about the potential difficulties and if/how they can be<br>
resolved.<br>
<br>
The difficulties I am talking about relate to dependency resolution. Given the<br>
current definition of Provides-Dist, it is possible for a package A on PyPI to<br>
"Provide" all of e.g. "A (1.0)", "B (1.2)" and "C (1.5)", and it is also<br>
possible for packages B and C on PyPI to provide the same (or slightly<br>
different) versions of logical packages of A, B, and C. This will likely lead<br>
to the need for a sophisticated dependency resolver because the dependency<br>
graph can get quite convoluted. (Remember, we might need to do this resolution<br>
when removing packages as well as when installing them.) I know there are SAT<br>
solvers and such, but I'm not sure we need that level of sophistication, or<br>
whether its complexity cost is outweighed by any benefit. Remember, we are<br>
managing fine without multi-valued Provides-Dist, and while a case has been<br>
made for virtual packages and forks (which just require a single-valued field),<br>
no compelling case has been made for bundling packages in general (I understand<br>
that such requirements might sometimes arise in certain corporate environments,<br>
but they don't seem to be a mainstream use case). Hence, no strong case has<br>
been made for a multi-valued "Provides" field.<br>
<br>
If we have a good index and packaging infrastructure, there is no general need<br>
for packages to bundle other packages, unless those bundled packages are changed<br>
in some way to suit the bundler's needs. In that case, I don't know how you<br>
could be sure that a bundled "A (1.0)" hasn't diverged from the equivalent<br>
package on PyPI.<br>
<br>
The "Provides" seems essentially useless in a metadata index, since if, when<br>
asked to install D which has a dependency on A, you would download and install<br>
A to resolve it rather than B or C, and I can't see when you would want to<br>
query the index to say "who provides A?" and then use some heuristic to pick<br>
e.g. B or C, rather than A.<br>
<br>
distlib currently contains support for the multi-valued "Provides", but I'm<br>
not confident that will work as expected given pathological cases like the<br>
example I suggested, without getting "complicated" in the Zen of Python sense.<br>
I'm not convinced that the maintenance burden of a complicated solution is<br>
worth the heretofore unnecessary ability to bundle stuff in arbitrary ways.<br></blockquote><div><br>If you don't have Provides-Dist, then distribute must continue to bundle an extra .egg-info directory to emulate the feature. This is more than enough justification for me. Name: is essentially an alias for Provides-Dist: (or vice-versa) so there is no such thing as a single-valued Provides-Dist. Having two names for a package is just as complicated as having twenty.<br>
<br>You should not implement Provides-Dist by searching for every Provides-Dist: name on PyPI. You should only use it when deciding whether to download setuptools when distribute is already installed and a package depends on setuptools.<br>
<br>The bundling term was bad wording on the part of the PEP. No one should ever include non-renamed copies of other dists in their dists "import six" vs. "import django.util.six". I've suggested a new wording in this thread.<br>
<br></div></div></div>