Publishing .whl next to .tar.gz in the same version breaks hash matching.

[wojked]

Issue description

This is not an issue related to the orderedmultidict but I will use it as the example.
I had my pipfile locked on orderedmultidict 1.0 (please note there used to be only one hash until 3 days ago)

"orderedmultidict": 
{
             "hashes": [ "sha256:b89895ba6438038d0bdf88020ceff876cf3eae0d5c66a69b526fab31125db2c5"],
             "version": "==1.0"
}

Everything worked as expected, until a new .whl was added to the "orderedmultidict" in PyPi.
Now, when trying to install it on a new environment (CI), it will fail due to hash mismatch:

11:52:47         Expected sha256 b89895ba6438038d0bdf88020ceff876cf3eae0d5c66a69b526fab31125db2c5
11:52:47              Got        24e3b730cf84e4a6a68be5cc760864905cf66abc89851e724bd5b4e849eaa96b

A previously absent .whl is preferred, even though the known tar.gz remains untouched.

Expected result

Any "additive" changes on https://pypi.org/project/orderedmultidict/1.0/#files (added .whl on August 31, 2018, 3 days ago) should not affect the hash matching as no code changes were released.

By an "additive" change I mean republishing a package in a new format, like adding a .whl next to .tar.gz.

I understand that wheels are the new, preferred packaging method, so alternatively, pipenv should inform about it's .whl preference and inform about new files (new hashes) being available instead of failing or forcing me to install a re-packaged version.

It should be possible to lock on a specific file format (if initially installed from a tar.gz it should not be obligatory to suddenly switch to the .whl version).

Actual result

Pipenv tries to install a newly added wheel and returns an error with a hash conflict, because a newly added file has obviously a different hash.

Steps to replicate

• Publish 'your_package' on pypi, without .whl (it will have its own SHA256 hash)
• Install the package with (pipenv install your_package)
• Re-publish 'your_package' on pypi just add a .whl (it add its own SHA256 hash)

Try to install the dependency in a new environment
pipenv install should fail due to hash mismatch

Work around

Reinstall the dependency
pipenv install orderedmultidict
it will add the hash of the new .whl file and install without any issues.

[uranusjr]

This is essentially the same problem described in #2618. Closing this so the feedback can be centralised. The feature is working as intended in a sense, but we would very much welcome any suggestions to improve the ergonomics.