On Jan 16, 2014, at 9:52 PM, Hannes Schmidt <hannes@ucsc.edu> wrote:

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.

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. 

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.

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?

[1]: https://mail.python.org/pipermail/distutils-sig/2013-October/022937.html

Pip 1.5 has already been released which turns dependency links off by

default and adds a flag —process-dependency-links and they are

scheduled to be removed in 1.6. It’s possible we can “undeprecate” them

and leave them off by default however my question to you would be why

you can’t use a requirements.txt file to handle installing things from bitbucket?

Fundamentally a setup.py should not contain “concrete” locations but instead

should contain abstract names/version specifiers whereas a requirements.txt

(or the pip invocation itself) takes those abstract names and makes them

concrete by pairing them with an index.

So to be more explicit, is there any reason why one of:

1) Create a requirements.txt and point to bitbucket in that and install your

    environment using ``pip install -r requirements.txt``

2) Create tar balls of your packages and host them in a directory somewhere

    behind nginx and use —find-links https://example.com/that-directory/ as

    your install location.

Won’t work just as fine for you?

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA