This would occur when, for example, installing from a requirements file that references a certain hashed sdist, a common situation.
As of pip 7, pip always tries to build a wheel for each requirement (if one wasn't provided directly) and installs from that. The way this was implemented, InstallRequirement.link pointed to the cached wheel, which obviously had a different hash than the index-sourced archive, so spurious mismatch errors would result.
Now we no longer read from the wheel cache in hash-checking mode.
Make populate_link(), rather than the `link` setter, responsible for mapping InstallRequirement.link to a cached wheel. populate_link() isn't called until until prepare_files(). At that point, when we've examined all InstallRequirements and their potential --hash options, we know whether we should be requiring hashes and thus whether to use the wheel cache at all.
The only place that sets InstallRequirement.link other than InstallRequirement itself is pip.wheel, which does so long after hashes have been checked, when it's unpacking the wheel it just built, so it won't cause spurious hash mismatches.
Renaming "gots" didn't go well. I think the current naming is the most concise way to put it. If we rename it to "got", then the loop iterator can't be called "got", and the simple relationship between the iterator and collection names is lost. "Actual" and "actuals" are the other names that occurred to me, but they look so much like "allowed" that the code becomes harder to read.
We don't need to talk about the network, since HTTPS should ensure transmission integrity. We do need to watch out for the CA chain. Stop mentioning the CDN because it's a deep hole: we might as well mention Rackspace and Amazon and who knows who else.
This guards against the possibility of a weaker hash being added to hashlib in the future. Also give _good_hashes() a more descriptive name, and describe what we mean by "strong".
We can get away with returning a static list because those algorithms are guaranteed present in hashlib.
An info-level message for each package might be too intense. And it might give a false sense of security as well: it doesn't confirm that the virtualenv is non-empty; it merely notices when a package we're installing is already there.
Those commands already checked hashes, since they use RequirementSet, where the hash-checking is done.
Reorder some options so pre, no-clean, and require-hashes are always in the same order.
