<div><span style="color: rgb(160, 160, 168); ">On Friday, September 21, 2012 at 3:09 PM, PJ Eby wrote:</span></div>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div>On Fri, Sep 21, 2012 at 12:59 PM, Donald Stufft <<a href="mailto:donald.stufft@gmail.com">donald.stufft@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>How would you take ``requires: tastypie`` and turn it into</div><div>`django-tastypie`?</div></div></blockquote><div><br></div><div>By matching Requires with Provides at the index level.  That is, by</div><div>having PyPI index packages' Provides so that you can search for</div><div>packages that match a given Requires.</div></div></div></span></blockquote><div>And when you have 2 packages that both provides: tastypie? Which is a real</div><div>world occurence. I actually got my projects switched up, it's haystack and</div><div>django-haystack which have different names on PyPI (and entirely different functions)</div><div>but are both ``import haystack`` and thus would both be Provides: haystack.</div><div><br></div><div><a href="https://crate.io/packages/haystack/">https://crate.io/packages/haystack/</a></div><div><a href="https://crate.io/packages/django-haystack/">https://crate.io/packages/django-haystack/</a></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><blockquote type="cite"><div><div>This makes them better than I thought, but still have the "installability"</div><div>and</div><div>security.</div></div></blockquote><div><br></div><div>How is this any different than any other part of PyPI?</div></span></blockquote><div>I hate it there too and I've done a little bit to try and make it more obvious</div><div>to people when people rely on dependencies that aren't hosted on PyPI and</div><div>I plan to do more in the future. (I realize the historical significance of it, I just</div><div>don't think it should bind us to be stuck with it forever). But that's a separate</div><div>argument for a different day.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div>I would have to dig into the code to be sure, actually.  But I don't</div><div>see any problem with restricting them to the dependency subtree being</div><div>resolved.  It's possible that the current easy_install implementation</div><div>leaks dependencies to sibling installs, but if it does, it's probably</div><div>not hard to fix.</div></span></blockquote><div>I only asked this because if it works for siblings I could imagine a case</div><div>where someones install set worked, but then they remove a dependency</div><div>and suddenly unrelated installs stopped working. Not really pertinent to the</div><div>discussion at hand, just a possible bug (or surprising behavior) that popped</div><div>into my head. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div>Again: the entire point of dependency_links is to have an in-band,</div><div>automated way to ship third-party indexing information that would</div><div>otherwise require manual, out-of-band, *recursive* distribution.</div><div>Dependency links are download locations, and are independent of</div><div>version specifications.</div></span></blockquote><div>Yea I get that, I think at this point it's just a differing of opinion about</div><div>wether that is a desirable trait for a system to have or not. Obviously</div><div>I think not, and you I believe think it is. Setuptools isn't (and shouldn't)</div><div>be removing them and as you said they don't belong in PKG-INFO so I</div><div>I think we are in agreement about that :)</div><div><br>
                </div>