pip install -U shouldn't go to pypi if the requirement is already installed

[mbox]

Setup a virtualenv with all requirements in pip-reqs.txt installed (requirements that all have a specific version specified)

Running pip install -U and pip install should both be No-ops as nothing needs to be installed.

However the -U version runs about 1000x slower than the straight install:

 pip install -U -r pip-reqs.txt

 real   3m5.072s
 user   0m3.340s
 sys    0m0.970s

 pip install -r ../pip-reqs.txt

 real   0m0.246s
 user   0m0.160s
 sys    0m0.080s

Both runs end up not installing anything - although the -U version does hit two git repos (but it's every single check that's slower, so time isn't accounted for by these pulls)

Environment:

pip 1.2.1 running on Linux

[qwcode]

I'm assuming your requirements in pip-reqs.txt have specific versions?
in that case, your complaint is that pip install -U shouldn't be crawling for pypi updates like it's doing, when all it's going to end up doing is accepting the installed versions (because -U does not override requirement specifiers like project==1.1 even if 1.2 is available)
If that's your complaint, I think that's fair, but I'd like to change your title and description.

[mbox]

Yes, that's correct - all the packages in the pip-reqs.txt have versions, which are already installed.

So you're right - the bug is that it shouldn't go off to pypi unless the requirement is not already satisfied.

I've changed the title to reflect that.

[mbox]

Am I right in thinking the bug is here https://github.com/pypa/pip/blob/develop/pip/req.py#L1072 where if self.upgrade is set, the satisfied_by flag is reset - which presumably causes the update to pull from pypi?

[dstufft]

I'm going to close this, we've decided that we're not going to do this. With the new PEP 440 rules the == has slightly different meaning which makes it hard to do this reliably.