#egg=project-version not being parsed correctly

[mattbennett]

Using pip 1.4.1. Given the following requirements file:

pytest-cov==1.6
# patched version of coverage, to deal with eventlet
git+https://github.com/newbrough/coverage.git#egg=coverage-3.5.2pl1

pytest-cov only requires coverage>=3.4, and should be satisfied by the git package, but pip installs coverage 3.7 anyway.

$ pip install reqs
...
$ pip freeze
cov-core==1.7
coverage==3.5.2pl1
py==1.4.17
pytest==2.4.2
pytest-cov==1.6
wsgiref==0.1.2
$ python -c "import coverage; print coverage.__version__"
3.7

Our workaround is to pip install reqs again, which reinstalls coverage==3.5.2pl1.

[qwcode]

if you use git+https://github.com/newbrough/coverage.git#egg=coverage, it works.

But this is a bug, ""#egg=project-version" is a format that historically comes from setuptools, and pip should support it.
We're currently only supporting "#egg=project" in this use case.

I'm going to change the bug description to match the problem.

[qwcode]

I'll work on this.

[qwcode]

update: this is only a problem when not using -e (the -e case was fixed indirectly recently in develop branch)

[xavfernandez]

But this is a bug, ""#egg=project-version" is a format that historically comes from setuptools, and pip should support it.

The fact that - is both allowed in the project name and in the version makes this requirement impossible to abide by... This plus the fact that the version part is totally useless, I'd like to start deprecating it.
https://github.com/pypa/pip/blob/69d9044/pip/req/req_install.py#L1056-L1065 seems extremely fragile.

@qwcode any thought ?

Edit: or maybe it could be the occasion to start migrating away from #egg= and start expecting a #name=/#req=/#req_name=/#package= (this one without any version part) ?

[dstufft]

Closing as a duplicate of #3212.