MyPy dependency version issues when changing python3 interpreter version

[thundergolfer]

Currently the MyPy py_binary this integration ships gets its dependencies using rules_python's pip_import: https://github.com/thundergolfer/bazel-mypy-integration/blob/master/repositories/py_repositories.bzl#L22

It's configured to currently just look for python_interpreter = "python3", and now I'm not sure this would work when the underlying interpreter version changes, for example by going from 3.6 to 3.7.

Looking at the resolved typed_ast depending inside my Bazel WORKSPACE's outputBase I see:

cat bazel-data-science/external/mypy_integration_pip_deps_pypi__typed_ast_1_4_1/typed_ast-1.4.1.dist-info/WHEEL
Wheel-Version: 1.0
Generator: bdist_wheel (0.33.6)
Root-Is-Purelib: false
Tag: cp36-cp36m-macosx_10_9_x86_64

Which is clearly 3.6 versioned. If the python3 interpreter is upgraded to 3.7 what happens? I think the repository_rule that downloaded the dependencies wouldn't invalidate (because python_interpreter = or anything else hasn't changed), and the dependencies would be out-of-date.

Bazel docs for repository_rules mention the configure attr which indicates that a repository_rule "inspects the system for configuration purpose". Should this be set on the repository_rule that does deps downloading?

My current idea is that the python_interpreter attr of pip_import should be configurable for the user so that they can specify themselves which interpreter is being used, and have it match how they install dependencies for their WORKSPACE internal code.

[thundergolfer]

This issue has been ameliorated a bit by #32.

You can now pass through an interpreter like python3.7 which means you specify the minor version. But there's still a problem of what happens if your Python toolchains changes independently of this version (conflict) or if the minor version is upgraded and 3.7 is not longer available (failure). Neither scenario is ideal.

[thundergolfer]

Maybe #30 is an avenue to go down.