<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 16, 2014, at 9:52 PM, Hannes Schmidt <<a href="mailto:hannes@ucsc.edu">hannes@ucsc.edu</a>> wrote:</div><br class="Apple-interchange-newline"><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">https://mail.python.org/pipermail/distutils-sig/2013-October/022937.html</a></div></div></blockquote></div><br><div><br></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/">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></body></html>