<div><span style="color: rgb(160, 160, 168); ">On Friday, September 21, 2012 at 11:14 AM, 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>Yes, but that was still sufficient information to implement a</div><div>dependency system, in theory. Specifically, it would have worked for</div><div>the case where all projects are on PyPI and have correct metadata.</div><div><br></div><div>If you assume that condition, you can trivially solve all</div><div>dependencies; but if you don't assume that condition, you need</div><div>something like dependency links.</div></div></div></span></blockquote><div>How would you take ``requires: tastypie`` and turn it into `django-tastypie`? Remebering</div><div>that PyPI enforces a unique distribution name, not a unique python package (in the import</div><div>sense) name. In tastypie's case there are 2 libraries that both provide a top level ``tastypie``</div><div>import, one is on PyPI as just ``tastypie`` and the other is ``django-tastypie``.</div><div><br></div><div>That also sidesteps the issue that those fields were already in use and if they were</div><div>hijacked for this new purpose all that old data would (could?) have created issues. The</div><div>new meta-data sidestepped all these issues.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div>For the same reason that requiring someone to read the source code of</div><div>every function called by every function called by every function</div><div>called by code they use isn't an ok thing to do.</div></span></blockquote><div>As I said before, obviously you must draw the line somewhere. setuptools</div><div>choose to draw it at a different place than I believe it should have. I don't</div><div>believe saying "you must be using some combination of indexes that</div><div>include all the dependencies or else you'll need to manually fetch them" is</div><div>that large of a burden or requirement to make, obviously you disagree.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div>This is indeed wrong. Dependency links are a last resort, used after</div><div>all other provided dependency resolution sources have failed.</div></span></blockquote><div>This makes them better than I thought, but still have the "installability" and</div><div>security. The question this raises in my head, can they be used for any</div><div>dependency, or only dependencies that the distribution defining them has?</div><div>e.g. if I install Foo, and it depends on Bar, and Wat, and Bar has a</div><div>dependency_links, will it only work for Bar and it's dependencies</div><div>or will it work for Wat's dependencies as well? </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div>That's what --allow-hosts is for: easy_install can be locked down to</div><div>not install except from your local intranet or PyPI or whatever, and</div><div>it can be done on a sitewide basis by default (by settings in the</div><div>site's distutils.cfg).</div></span>
</blockquote>
<div>
I'd have been less uneasy about them if they were opt in instead of
</div><div>opt out, but that'd require a time machine. I'm mostly trying to stress</div><div>why I'm against them to make sure we don't repeat (in my opinion)</div><div>the mistakes of the past.</div><div><br></div><div>I should probably mention here that I don't particularly blame setuptools</div><div>for their invention, I think it's a side effect of one tool owning the entire</div><div>packaging chain from top to bottom and not any fault with the implementer(s)</div><div>and because easy_install (to my knowledge) does not have anything like</div><div>a requirements file from pip so without that the obvious place for these</div><div>"extra locations" is a setup.py. I just think it's better to split them out and</div><div>keep the packaging metadata abstract, and them have the concrete meta-data</div><div>be inferred by taking that abstract data and combining it with a requirements.txt</div><div>like file.</div>