Git+SSH dependencies have subtle (yet critical) differences from git clone

Reproduction steps:

1. Have a git repository which is private, and is a pip package.
2. Have a deploy key which can read the repository.
3. Confirm you can run git clone [e-mail]:account/private-pip-package.git
4. Google around and discover that the instructions to use a git repo as a pip dependency boil down to very nearly “prefixing the repo with git+ssh:// and suffix it with #egg=private-pip-package.”
5. End up with a pip dependency of git+ssh://[e-mail]:account/private-pip-package.git#egg=private-pip
6. Try installing the package, but get a fatal: Could not read from remote repository. instead.
7. Run the gamut of tests (ssh [e-mail] works, but ssh ssh://[e-mail] fails …)
8. Realize (after much hair-pulling) that instead of git+ssh://[e-mail]:account/private-pip-package.git#egg=private-pip it should be git+ssh://[e-mail]/account/private-pip-package.git#egg=private-pip (if you didn’t catch that, its github.com/account instead of github.com:account)

I would propose that a simple note in the failure message, or checking on input, or what have you, about the : vs. / would be quite helpful.

[remohammadi]

If you instead run setup(dependency_links=[‘git+ssh://[e-mail]/account/private-pip-package.git#egg=private-pip’], install_reqs=[‘private-pip-package’], …), you’ll get an error like Could not find any downloads that satisfy the requirement private-pip-package (from package==1.2.3).

Pip wants to know the version before fetching (git clone) the dependency. If we specify the version after the project name in the egg string, in this hacky form: egg=<project name>-<version>, then there will be an item in _find_all_versions()'s returned list, and everything goes fine. So if we want to dependent our package on the latest commit in the branch STABLE-X of a VCS repository, we can do this:

install_requires=[
    'private-pip-packag',
],
dependency_links=[
    'git+ssh://[e-mail]/account/private-pip-package.git@STABLE-X#egg=private-pip-9999999',
],

But, it’s too hacky! I think these days it’s so reasonable to have a project dependant on the latest version of a branch of some VCS repository, and there should be no need on specifying a dummy version number as a workaround for this purpose.

[ajmazurie]

Hi guys, I am having the very same problem of not being able to install a specific commit of a Github-hosted project using setuptools’ dependency_links option, and was wondering if this was still considered a bug or a misunderstanding of setuptools.

Say, for example, that I want to install a specific commit of the project paramiko-expect; for example, https://github.com/fgimian/paramiko-expect/tree/943630ac499284e6441854a9c4ae1e04301bfdd9

Here is what works and what doesn’t, using pip 8.1.2 and setuptools 23.1.0:

• 🆗 pip install "git+ssh://[e-mail]/fgimian/paramiko-expect.git@943630a#egg=paramiko-expect-0.2"
• 🚫 (in dependency_links in setup.py) git+ssh://[e-mail]/fgimian/paramiko-expect.git@943630a#egg=paramiko-expect-0.2
• 🚫 (in dependency_links in setup.py) https://github.com/fgimian/paramiko-expect/archive/943630ac499284e6441854a9c4ae1e04301bfdd9.zip#egg=paramiko-expect-0.2
• 🚫 (in dependency_links in setup.py) https://github.com/fgimian/paramiko-expect/zipball/943630a#egg=paramiko-expect-0.2

Note that the setup.py file then has paramiko-expect==0.2 in its install_requires field, and that I tried all possible variants of paramiko-expect versus paramiko_expect. The setup.py file is then used by typing pip install ..

Is there something I’m missing here? Best, Aurélien