Description
(Issue forked from #37.)
This issue tracks the fact that the Python interpreter used by pip_import (at WORKSPACE evaluation time) is not necessarily related in any way to the Python interpreter used by the toolchain (at analysis time). This is a consequence of the fact that toolchain information is not generally available at WORKSPACE evaluation time.
This can lead to confusion when the wrong major version of Python is used (before #249, it's hard to avoid this problem). It can be even more confusing when the discrepancy is only in minor version.
For major version, we could consider a modification to whl_library that sets srcs_version = "PY[2|3]ONLY". This would prevent accidental mixing of pip dependencies between PY2 vs PY3, at the expense of prohibiting the same pip package from being used for both when its sources support that use case. (We could also make this an optional feature, controlled by an attribute of pip_import.)
To address the stronger problem, where you want to guarantee that exactly the same interpreter gets used at both WORKSPACE eval time and analysis, it's not clear what we can do. Perhaps we could have a repo macro/rule that generates the toolchain in such a way that it's the same system interpreter as is passed to pip_import. Then at least users who use this construct wouldn't have a problem.
Note that it doesn't make sense to use the same interpreter for WORKSPACE eval and analysis if the interpreter is not a prebuilt binary, since Bazel can't build its own tools at WORKSPACE eval time.