Idea: Capture expected Python version & artifact names in Pipfile.lock to improve error messages

Working on a pipenv based development setup in https://github.com/leapp-to/prototype/pull/8 we’re finding it fairly easy for people to get into a situation where they accidentally create the venv with Python 2, but the lock file was generated with Python 3, so the hashes for pre-built wheel files may not match.

Example from https://github.com/leapp-to/prototype/pull/8#issuecomment-289438239:

 $ sha256sum ~/Downloads/cffi-1.10.0*
267dd2c66a5760c5f4d47e2ebcf8eeac7ef01e1ae6ae7a6d0d241a290068bc38  /home/podvody/Downloads/cffi-1.10.0-cp34-cp34m-manylinux1_x86_64.whl
4fc9c2ff7924b3a1fa326e1799e5dd58cac585d7fb25fe53ccaa1333b0453d65  /home/podvody/Downloads/cffi-1.10.0-cp35-cp35m-manylinux1_x86_64.whl
e7175287f7fe7b1cc203bb958b17db40abd732690c1e18e700f10e0843a58598  /home/podvody/Downloads/cffi-1.10.0-cp36-cp36m-manylinux1_x86_64.whl
b3b02911eb1f6ada203b0763ba924234629b51586f72a21faacc638269f4ced5  /home/podvody/Downloads/cffi-1.10.0.tar.gz

@shaded-enmity and I thought of two possible ways to make the resulting hash mismatch errors less confusing:

1. Record the implementation and version of Python used to generate the lock file in the lock file, since that may affect the pre-built wheel files that pip finds and downloads
2. For each locked artifact, record the filename in addition to the hash

For the first option, any hash mismatches would be preceded by a warning that the Python versions didn’t match so the lock file may need to be regenerated.

For the second, if a hash mismatch was found, it would be reported as a filename mismatch first, and only reported as a hash mismatch if the filenames matched.

[kennethreitz]

✨🍰✨

[kennethreitz]

This is now released!