<div dir="ltr">Thank you for your suggestions, Donald. They are both feasible but they feel like workarounds to me.<div><br></div><div>Manually listing transitive dependencies seems like a step backwards to me. Isn't the whole point of setuptools/distutils that each component manages its own list of dependencies? How will this scale to dozens of transitive dependencies and busy development teams where dependencies are revved frequently. I really liked what Maven did for Java and therefore liked what pip is trying to do for Python.</div>
<div><br></div><div>I haven't used --find-links yet so I may be wrong but tarring up packages and serving them by a web server is additional work that I'd rather avoid. It just creates yet another copy of the package and requires maintaining an additional server component.</div>
<div><br></div><div>I loved the fact that I could point pip directly at my source repos for both my top-level projects as well as their dependencies. That seemed like a perfect fit for an interpreted language like Python where packages are distributed in source form. Removing dependency_links makes that feature useless to me because it doesn't extend to dependencies, only top level components.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 4:44 AM, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Jan 16, 2014, at 9:52 PM, Hannes Schmidt <<a href="mailto:hannes@ucsc.edu" target="_blank">hannes@ucsc.edu</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">I read through the "Removing dependency_links" thread [1] and I beg you not follow through with the deprecation and removal of dependency_links and to rethink your approach.<div>
<br></div><div>The mentioned thread indicates that research was done to gauge the popularity of the dependency_links in publicly hosted Python projects. That approach is fundamentally flawed: Publicly hosted projects are much more likely to also be available on PyPI than private, closed-source projects. Consequently, their dependencies are also more likely to be hosted on PyPI as well. Because of that, they are much less likely to rely on the dependency_links feature. </div>

<div><br></div><div>Another misconception seem to be that dependency_links is predominantly used for installing patched or customized versions of dependencies hosted on PyPI. I'm pretty sure the predominant use case for dependency_links is with projects that are hosted privately, e.g. for an organization's internal use. I represent such an organization and removing dependency_links would impact us negatively. We host a set of internal projects and their dependencies on Bitbucket and we rely on dependency_links to install them directly from there.</div>

<div><br></div><div>I understand the motivation for this change – security – but there must be smarter way to handle it. Could we fallback to dependency_links if a PyPI lookup isn't successful? Could we restrict dependency_links to links that share a prefix with the link from which the package is currently being installed? A combination of the two?</div>

<div><br></div><div>[1]: <a href="https://mail.python.org/pipermail/distutils-sig/2013-October/022937.html" target="_blank">https://mail.python.org/pipermail/distutils-sig/2013-October/022937.html</a></div></div></blockquote>
</div><br><div><br></div></div></div><div>Pip 1.5 has already been released which turns dependency links off by</div><div>default and adds a flag —process-dependency-links and they are</div><div>scheduled to be removed in 1.6. It’s possible we can “undeprecate” them</div>
<div>and leave them off by default however my question to you would be why</div><div>you can’t use a requirements.txt file to handle installing things from bitbucket?</div><div><br></div><div>Fundamentally a setup.py should not contain “concrete” locations but instead</div>
<div>should contain abstract names/version specifiers whereas a requirements.txt</div><div>(or the pip invocation itself) takes those abstract names and makes them</div><div>concrete by pairing them with an index.</div><div>
<br></div><div>So to be more explicit, is there any reason why one of:</div><div><br></div><div>1) Create a requirements.txt and point to bitbucket in that and install your</div><div>    environment using ``pip install -r requirements.txt``</div>
<div>2) Create tar balls of your packages and host them in a directory somewhere</div><div>    behind nginx and use —find-links <a href="https://example.com/that-directory/" target="_blank">https://example.com/that-directory/</a> as</div>
<div>    your install location.</div><div><br></div><div>Won’t work just as fine for you?</div><div><br></div><div><br></div><div>
<br>-----------------<br>Donald Stufft<br>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

</div>
<br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Hannes Schmidt<br>Software Application Developer<br>Data Migration Engineer<br>Cancer Genomics Hub<br>University of California, Santa Cruz<br>
<br>(206) 696-2316 (cell)<br><a href="mailto:hannes@ucsc.edu" target="_blank">hannes@ucsc.edu</a></div>
</div>