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 [email protected]:My/repo.git@master#egg=repo at [email protected]: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://[email protected]/My/repo.git is accepted by both.

I'd be more in favor of dropping support of the unholy, pip-specific [email protected]:My/repo.git syntax.

[Ivoz]

@xavfernandez minus the git+ (which is the pip specific part to any VCS url), [email protected]: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('[email protected]:My/repo.git')
ParseResult(scheme='', netloc='', path='[email protected]:My/repo.git', params='', query='', fragment='')
>>> urlparse('git+ssh://[email protected]/My/repo.git')
ParseResult(scheme='git+ssh', netloc='[email protected]', 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]

[email protected]: 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 [email protected]:shelldweller/etlite.git#egg=etlite
Invalid requirement: '[email protected]:shelldweller/etlite.git#egg=etlite'
It looks like a path. File '[email protected]:shelldweller/etlite.git#egg=etlite' does not exist.

# neither does git+ssh:
pip install [email protected]:shelldweller/etlite.git#egg=etlite
Invalid requirement: '[email protected]:shelldweller/etlite.git#egg=etlite'
It looks like a path. File '[email protected]: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 [email protected]:shelldweller/etlite.git#egg=etlite
Obtaining etlite from [email protected]:shelldweller/etlite.git#egg=etlite
  Cloning [email protected]:shelldweller/etlite.git to ./.venv/src/etlite
...

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

pip install [email protected]:shelldweller/etlite.git#egg=etlite
Invalid requirement: '[email protected]:shelldweller/etlite.git#egg=etlite'
= is not a valid operator. Did you mean == ?

# but in editable mode it's fine:
install -e [email protected]:shelldweller/etlite.git#egg=etlite
Obtaining etlite from [email protected]:shelldweller/etlite.git#egg=etlite
  Cloning [email protected]:shelldweller/etlite.git
...

All examples are reproduced with pip 19.0.1 and Python 3.6.7.

[xavfernandez]

What you want is git+ssh://[email protected]/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://[email protected]/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://[email protected]/user works but git+ssh://[email protected]: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.