Don't deprecate dependency_links or let pip use a requirements.txt file when installing from git

[wrouesnel]

In trying to find a lightweight way to distribute python scripts within an organization, the proposed situation with pip as implied by the deprecation messages is absurd.

You can easily distribute a single package on a git server (something most organizations have)...but you can't easily distribute a package which might depend on a few other internal packages.

If pip removes dependency_links processing, then this style of distribution will become completely impossible - which to me stands in stark contrast to something like npm which makes doing this absurdly easy.

Sure, don't make it implicit - but there needs to be an easy way where I can send a coworker a single line command which will pip install a package which has a bunch of other git dependencies.

The ideal solution would be a way to force pip to process the requirements.txt file from a git repository, so the repository could define it's other requirements specifically (since this is something a library in a git repository definitely does).

Perfect would be something like:
pip install --follow-requirements git+http://my.internal.gitserver/internallibrary.git

Maybe give a prompt for the untrusted requirements?

[dstufft]

We're not going to remove dependency links until the replacement for them (that PyPI understands and can enforce that you don't upload packages relying on them) is implemented.

[connorbode]

@dstufft What is this replacement?

I have two packages PackageA and PackageB stored in private Git repositories, and an application App. App depends on PackageA, and PackageA depends on PackageB. I have found no way to install PackageB automatically as a dependency of PackageA when installing App's requirements.

[RonnyPfannschmidt]

@connorbode how about setting up a devpi index with the releases, then you can point pip to the devpi as index and wont need any dependency links and it will also mirror/cache pypi in your work network