fix(pip/req/req_set): Dont err on double reqs of the same spec

[kaustavha]

If double requirements exist with the same specs, dont raise a double requirement given error.

My reasoning is that if the user has the same version specified in more than one place this is an unnecessary level of hand holding and this error prevents people from writing more modular requirements.txts more than it prevents bugs.
If separate versions exist multiple times it makes sense to error out/ use a dependency resolver as discussed in #988 .

Fixes #993.

This does not affect #2367.
This is not related to #1658. I've noticed that if two git+... links are given with different egg names this code block doesn't affect them and it will happily install them even without the req.specs check. Checked on py 3.5.1 and 2.7.10.

[xavfernandez]

Seems ok, a test would be nice :)

[kaustavha]

@xavfernandez I have complied with your demands; merge away! Or make more demands of this pr and I will most likely comply

[xavfernandez]

Thanks :)

[zsalzbank]

Any word on when this will make it into an official release?

[nikolay]

@kaustavha This still doesn't work for me. I have a requirements.txt file and also a requirements-common.txt file that doesn't have any versions specific and is included into requirements.txt via the -r command. I also have a requirements.txt.lock file, which is the frozen versions. Unfortunately, for whatever reason, the frozen requirements still has -r requirements-common.txt in it and thus it finds the same package without a version and also with a specific version, considers those different, and errors out. I'm using the latest version of pip, i.e. 8.1.2 as of this moment.

[kaustavha]

@nikolay Sorry for the late reply.
tl;dr: Try just adding the version used in reqs.txt to reqs-common.txt.

If I am understanding you correctly, youre trying to do something slightly different than what I wrote here. Take a look at the test case in the pr.

So case 1:
req.txt

someDep 0.0.1
-r req-common.txt

req-common.txt

someDep *

In this case, pip cannot safely decide which version to pull.
What if the head has new problems? What if the programmer actually wants to be lazy everywhere and use * but the 0.0.1 came from some template code he copied and that version is now deprecated?

Now case 2:

req.txt

someDep 0.0.1
-r req-common.txt

req-common.txt

someDep 0.0.1

In this case, the code in this PR will check that both of the versions match and are consistent. Pip doesn't need to do any guessing, we've used the same version throughout. So instead of complaining and saying the requirement was specified twice it carries onto the next step.

Furthermore you can take a look at how deps are set up on this project.
https://github.com/rackerlabs/mimic/tree/master/requirements
iirc I made this PR stemming from errors building mimic and conversations with its author.

[piotr-dobrogost]

What is someDep * supposed to mean?

[Brendenvski]

its just an example of a dependency, so for example flask 0.2.2 would be a example