Improve error message when host tools built for PY3 fail #8549
Assignees
Labels
P1
I'll work on this now. (Assignee required)
team-Rules-Python
Native rules for Python
type: feature request
Comments
brandjon
added
type: feature request
P1
laurentlb
pushed a commit
that referenced
this issue
Jun 6, 2019
We already emit a diagnostic message when the host config's Python version overrides a Python tool's normal version. This helps users know to add --host_force_python=PY2 to their bazelrc. Without it, all they'd see is a confusing Python stack trace. With this change, we also emit a diagnostic message when the target's python_version attribute is omitted and the user has not set --host_force_python=PY2. This covers the case where both the target and the host config default to PY3, but the target was really intended to be a Python 2 target. Previously, this case sometimes worked anyway due to #4815, but with Python toolchains enabled it breaks and we need to help the user understand the breakage. In all cases the diagnostic is still only printed when the target has non-zero exit code and is built in host config. See also #7899. Fixes #8549. RELNOTES: None PiperOrigin-RevId: 251496135
laurentlb
pushed a commit
that referenced
this issue
Jun 7, 2019
We already emit a diagnostic message when the host config's Python version overrides a Python tool's normal version. This helps users know to add --host_force_python=PY2 to their bazelrc. Without it, all they'd see is a confusing Python stack trace. With this change, we also emit a diagnostic message when the target's python_version attribute is omitted and the user has not set --host_force_python=PY2. This covers the case where both the target and the host config default to PY3, but the target was really intended to be a Python 2 target. Previously, this case sometimes worked anyway due to #4815, but with Python toolchains enabled it breaks and we need to help the user understand the breakage. In all cases the diagnostic is still only printed when the target has non-zero exit code and is built in host config. See also #7899. Fixes #8549. RELNOTES: None PiperOrigin-RevId: 251496135
irengrig
pushed a commit
to irengrig/bazel
that referenced
this issue
Jun 18, 2019
We already emit a diagnostic message when the host config's Python version overrides a Python tool's normal version. This helps users know to add --host_force_python=PY2 to their bazelrc. Without it, all they'd see is a confusing Python stack trace. With this change, we also emit a diagnostic message when the target's python_version attribute is omitted and the user has not set --host_force_python=PY2. This covers the case where both the target and the host config default to PY3, but the target was really intended to be a Python 2 target. Previously, this case sometimes worked anyway due to bazelbuild#4815, but with Python toolchains enabled it breaks and we need to help the user understand the breakage. In all cases the diagnostic is still only printed when the target has non-zero exit code and is built in host config. See also bazelbuild#7899. Fixes bazelbuild#8549. RELNOTES: None PiperOrigin-RevId: 251496135
irengrig
pushed a commit
to irengrig/bazel
that referenced
this issue
Jul 15, 2019
We already emit a diagnostic message when the host config's Python version overrides a Python tool's normal version. This helps users know to add --host_force_python=PY2 to their bazelrc. Without it, all they'd see is a confusing Python stack trace. With this change, we also emit a diagnostic message when the target's python_version attribute is omitted and the user has not set --host_force_python=PY2. This covers the case where both the target and the host config default to PY3, but the target was really intended to be a Python 2 target. Previously, this case sometimes worked anyway due to bazelbuild#4815, but with Python toolchains enabled it breaks and we need to help the user understand the breakage. In all cases the diagnostic is still only printed when the target has non-zero exit code and is built in host config. See also bazelbuild#7899. Fixes bazelbuild#8549. RELNOTES: None PiperOrigin-RevId: 251496135
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The default host config Python version is PY3, but many host tools are written for Python 2. With
--incompatible_use_python_toolchainsbeing flipped, a common mode of failure is that these tools now fail for downstream users who do not know to set--host_force_python=PY2. This previously worked because we were ignoring the Python version and just callingpython, which on most systems is Python 2 (#4815).We already have a diagnostic message for host tools that exit with a non-zero code, in the case where the target's
python_versiondisagrees with the host config's Python version. But this message does not fire when there is nopython_versionattribute set and no--host_force_pythonpassed, since both of these default to PY3. I propose we extend this message to also fire whenpython_versionis not explicitly set. That will cover the common case and help alert downstream users to the changed needed in their bazelrc.Looking to cherrypick into 0.27.
The text was updated successfully, but these errors were encountered: