-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Status of process-dependency-links? #3939
Comments
The status is we want to get rid of it, it's deprecated, but there is an edge case that still needs it that we're not comfortable breaking yet until there is a replacement. |
If it's deprecated, what is the replacement to use when a package depends on another package that's in a private git repo? |
@dstufft I have the same question. If this is deprecated, is there a proposed alternative people should be using? |
Is this already implemented for pip/setuptools? if not, any schedule for this? |
use requirements.txt |
The alternative options for pulling from private git repos are pretty cumbersome to use. It seems pretty insane to remove the --process-dependency-links feature since it is already opt-in. This (sadly) seems like just another example of why python package/dependency management is such a ghetto compared to other modern languages ... |
So, here's the main issue: If I don't want to use a This doesn't work: [options]
install_requires =
requests==2.18.4
https://github.com/example/example_lib/archive/master.zip I also think dependency links are weird and fine to drop, but canonically how is this use case served if not with those? |
Further, suppose your dependency links are from an internal source, like a company enterprise GitHub instance. If I am writing an internal Python package that depends on other internal Python packages, specifying their dependency links directly in either Currently in some internal projects, this means I cannot use requirements.txt, because it lacks proper support for dependency links. Thus, I am forced to use Basically, a Python package dependency is a thing that can come from anywhere. If a tool doesn't allow me to articulate specific locations for each individual package, then that tool is functionally not a package management tool. In this sense, if pip moves forward with deprecating dependency links, pip would become some sort of tool that is not a package management tool. Even more, to stay relevant with growing multiplicity of ways to describe and manage packages (different source control sources, conda recipes), pip should be extending features and support for dependency links and adding more features for this type of use case, not taking them away or limiting them. |
PEP 508 has an example of how URL based requirements are to be located... https://www.python.org/dev/peps/pep-0508/#examples
Support for this will land as a part of pip 10; as #4175 has merged. |
so... what do we do now? How do I specify a git repo as a pip dependency (install_requires in setup.py)? For example when a project hasn't updated their pypy package, but code on github works!? |
If you have a URL for a specific sdist that you want to install, use a URL link to that sdist (but to be clear, it needs to be a static URL that contains a specific version - pointing at "master" won't work as there's no way pip can know when master gets updated). If you want to use the |
For posterity, with github you can ask for a tarball for some ref install_requires = [
'somerepo @ https://api.github.com/repos/User/somerepo/tarball/v0.1.1',
], |
Crazy, but this works like a charm even if the link you are providing is not on Github. |
Unfortunately the "install_requires" hack is useless for the main reason people would want to use it- for private repositories. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
What's the status of dependency links? I can't seem to find any notice of deprecation in the docs.
But when I use it with pip I get this notice:
Although the deprecation PR was reverted: #1955
Clarity would be super - thanks
The text was updated successfully, but these errors were encountered: