-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.24 RC has buggy Python verison select() behavior #7615
Labels
Comments
brandjon
added
type: bug
P1
I'll work on this now. (Assignee required)
release blocker
team-Rules-Python
Native rules for Python
labels
Mar 4, 2019
bazel-io
pushed a commit
that referenced
this issue
Mar 4, 2019
The target @bazel_tools//tools/python:python_version can be used with select() to determine the Python version in the current configuration. However, it was not updated when --incompatible_py3_is_default was added to switch the default to PY3. This meant that if neither --force_python nor --python_version was passed to the build, but --incompatible_py3_is_default was set, it would incorrectly return PY2 when the actual version was PY3. This CL updates this target's definition to take that flag into account. Fixes the bug in (but does not close) #7615. RELNOTES: None PiperOrigin-RevId: 236642947
As per discussion in #6968, this issue can be closed since the code changes are merged in master. |
katre
pushed a commit
that referenced
this issue
Mar 7, 2019
The target @bazel_tools//tools/python:python_version can be used with select() to determine the Python version in the current configuration. However, it was not updated when --incompatible_py3_is_default was added to switch the default to PY3. This meant that if neither --force_python nor --python_version was passed to the build, but --incompatible_py3_is_default was set, it would incorrectly return PY2 when the actual version was PY3. This CL updates this target's definition to take that flag into account. Fixes the bug in (but does not close) #7615. RELNOTES: None PiperOrigin-RevId: 236642947
katre
pushed a commit
that referenced
this issue
Mar 7, 2019
The target @bazel_tools//tools/python:python_version can be used with select() to determine the Python version in the current configuration. However, it was not updated when --incompatible_py3_is_default was added to switch the default to PY3. This meant that if neither --force_python nor --python_version was passed to the build, but --incompatible_py3_is_default was set, it would incorrectly return PY2 when the actual version was PY3. This CL updates this target's definition to take that flag into account. Fixes the bug in (but does not close) #7615. RELNOTES: None PiperOrigin-RevId: 236642947
katre
pushed a commit
that referenced
this issue
Mar 8, 2019
The target @bazel_tools//tools/python:python_version can be used with select() to determine the Python version in the current configuration. However, it was not updated when --incompatible_py3_is_default was added to switch the default to PY3. This meant that if neither --force_python nor --python_version was passed to the build, but --incompatible_py3_is_default was set, it would incorrectly return PY2 when the actual version was PY3. This CL updates this target's definition to take that flag into account. Fixes the bug in (but does not close) #7615. RELNOTES: None PiperOrigin-RevId: 236642947
katre
pushed a commit
that referenced
this issue
Mar 13, 2019
The target @bazel_tools//tools/python:python_version can be used with select() to determine the Python version in the current configuration. However, it was not updated when --incompatible_py3_is_default was added to switch the default to PY3. This meant that if neither --force_python nor --python_version was passed to the build, but --incompatible_py3_is_default was set, it would incorrectly return PY2 when the actual version was PY3. This CL updates this target's definition to take that flag into account. Fixes the bug in (but does not close) #7615. RELNOTES: None PiperOrigin-RevId: 236642947
katre
pushed a commit
that referenced
this issue
Mar 19, 2019
The target @bazel_tools//tools/python:python_version can be used with select() to determine the Python version in the current configuration. However, it was not updated when --incompatible_py3_is_default was added to switch the default to PY3. This meant that if neither --force_python nor --python_version was passed to the build, but --incompatible_py3_is_default was set, it would incorrectly return PY2 when the actual version was PY3. This CL updates this target's definition to take that flag into account. Fixes the bug in (but does not close) #7615. RELNOTES: None PiperOrigin-RevId: 236642947
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Background
The Python version used for
py_binary
targets can be affected by multiple command-line flags. In order to give the right answer forselect()
s that consume the Python version, the target@bazel-tools//tools/python:python_version
(and its wrappers,:PY2
and:PY3
) mirrors the same logic Bazel uses to decide the Python version. It's important thatselect()
sees the correct version or else action conflicts can arise.Bug
Bazel 0.24 introduces
--incompatible_py3_is_default
to change the default Python version. But it did not update the definition of the:python_version
target. This means that users could get broken builds when they enable--incompatible_py3_is_default
even when the underlying Python targets are properly compatible with Python 3.The fix is straightforward and low risk for cherrypicking into 0.24.
Repro
The text was updated successfully, but these errors were encountered: