pip requires the "-e" option to install from a scheme that starts with "git+git@"

[Kentzo]

Looks like it's not recognized and passed further into pkg_resources:

Exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/site-packages/pip/basecommand.py", line 223, in main
    status = self.run(options, args)
  File "/usr/local/lib/python3.4/site-packages/pip/commands/install.py", line 270, in run
    wheel_cache
  File "/usr/local/lib/python3.4/site-packages/pip/basecommand.py", line 275, in populate_requirement_set
    wheel_cache=wheel_cache
  File "/usr/local/lib/python3.4/site-packages/pip/req/req_install.py", line 212, in from_line
    wheel_cache=wheel_cache, constraint=constraint)
  File "/usr/local/lib/python3.4/site-packages/pip/req/req_install.py", line 66, in __init__
    req = pkg_resources.Requirement.parse(req)
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 2980, in parse
    reqs = list(parse_requirements(s))
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 2924, in parse_requirements
    "version spec")
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 2889, in scan_list
    raise RequirementParseError(msg, line, "at", line[p:])
pip._vendor.pkg_resources.RequirementParseError: Expected version spec in git+git@github.com:My/repo.git@master#egg=repo at +git@github.com:My/repo.git@master#egg=repo

[ajk8]

+1

[ghost]

+1

[RonnyPfannschmidt]

isnt it ssh+git?

[RonnyPfannschmidt]

whops, the other way around

[dmytroleonenko]

+1

[averges]

+1

[xavfernandez]

Well the valid url: git+ssh://git@github.com/My/repo.git is accepted by both.

I'd be more in favor of dropping support of the unholy, pip-specific git+git@github.com:My/repo.git syntax.

[Ivoz]

@xavfernandez minus the git+ (which is the pip specific part to any VCS url), git@github.com:My/repo.git is git specific, not pip specific. git docs say it is scp-like / accepted by ssh.

[xavfernandez]

I understand that, I just find it strange we needed to invent our own url like syntax.

>>> urlparse('git+git@github.com:My/repo.git')
ParseResult(scheme='', netloc='', path='git+git@github.com:My/repo.git', params='', query='', fragment='')
>>> urlparse('git+ssh://git@github.com/My/repo.git')
ParseResult(scheme='git+ssh', netloc='git@github.com', path='/My/repo.git', params='', query='', fragment='')

cc @rbtcollins @dstufft whether this needs to be added to PEP508

(For the record, I'd be in favor of dropping it)

[rbtcollins]

git+git@github.com: is not a URL - its an ssh style host reference, not a URL/URI.. https://www.ietf.org/proceedings/59/I-D/draft-ietf-secsh-scp-sftp-ssh-uri-01.txt covers ssh uri's, though its only a draft, and http://www.iana.org/assignments/uri-schemes/prov/git covers git:// urls - dropping support for the host reference stuff from pip is entirely appropriate.

[pradyunsg]

@dstufft @pfmoore @xavfernandez @rbtcollins Thoughts on this?

I'm in favour of deprecating and then dropping support for git+git; printing a message saying use git+shh instead.

[shelldweller]

It's actually the same problem with git+ssh. Only git+https works in non-editable mode which appears to contradict documentation.

Here's what I get:

# git+git doesn't work:
pip install git+git@github.com:shelldweller/etlite.git#egg=etlite
Invalid requirement: 'git+git@github.com:shelldweller/etlite.git#egg=etlite'
It looks like a path. File 'git+git@github.com:shelldweller/etlite.git#egg=etlite' does not exist.

# neither does git+ssh:
pip install git+ssh@github.com:shelldweller/etlite.git#egg=etlite
Invalid requirement: 'git+ssh@github.com:shelldweller/etlite.git#egg=etlite'
It looks like a path. File 'git+ssh@github.com:shelldweller/etlite.git#egg=etlite' does not exist.

# But git+https does:
pip install git+https://github.com/shelldweller/etlite.git
Collecting git+https://github.com/shelldweller/etlite.git
...

# And so does "editable" mode:
pip install -e git+git@github.com:shelldweller/etlite.git#egg=etlite
Obtaining etlite from git+git@github.com:shelldweller/etlite.git#egg=etlite
  Cloning git@github.com:shelldweller/etlite.git to ./.venv/src/etlite
...

Additionally on Windows, non-editable mode is broken in a different way:

pip install git+git@github.com:shelldweller/etlite.git#egg=etlite
Invalid requirement: 'git+git@github.com:shelldweller/etlite.git#egg=etlite'
= is not a valid operator. Did you mean == ?

# but in editable mode it's fine:
install -e git+git@github.com:shelldweller/etlite.git#egg=etlite
Obtaining etlite from git+git@github.com:shelldweller/etlite.git#egg=etlite
  Cloning git@github.com:shelldweller/etlite.git
...

All examples are reproduced with pip 19.0.1 and Python 3.6.7.

[xavfernandez]

What you want is git+ssh://git@github.com/shelldweller/etlite.git#egg=etlite

[shelldweller]

Um... I was saying that git+ssh behaves just like git+git and that (contrary to documentation) neither supports non-editable mode. Occasionally it may be desirable to pip install from git+ssh without the -e option.

[xavfernandez]

The documentation might be clearer but from https://pip.pypa.io/en/latest/reference/pip_install/#git:
git+git installation only works in editable mode (hence the -e) but git+ssh works in editable and non-editable mode (hence the [-e]).
pip install git+ssh://git@github.com/shelldweller/etlite.git#egg=etlite works fine.

[shelldweller]

I see. Thanks @xavfernandez. The confusion (at least for me) comes from the differences in URL format:
git+ssh://git@github.com/user works but git+ssh://git@github.com:user doesn't. Interestingly all major VCS providers (Github, Bitbucket, GitLab) give you SSH clone URL in the latter format. It is not obvious at all that one has to tweak the URL for it to work in non-editable mode.

[sbidoul]

Closing as we propose to remove the git+git@ form in #7554.