Skip to content
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

Closed
brandjon opened this issue Mar 4, 2019 · 1 comment
Closed

0.24 RC has buggy Python verison select() behavior #7615

brandjon opened this issue Mar 4, 2019 · 1 comment
Assignees
Labels
P1 I'll work on this now. (Assignee required) team-Rules-Python Native rules for Python type: bug

Comments

@brandjon
Copy link
Member

brandjon commented Mar 4, 2019

Background

The Python version used for py_binary targets can be affected by multiple command-line flags. In order to give the right answer for select()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 that select() 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

# BUILD
sh_binary(
    name = "foo",
    srcs = select({
        "@bazel_tools//tools/python:PY2": ['py2.sh'],
        "@bazel_tools//tools/python:PY3": ['py3.sh'],
    }),
)
# py2.sh
echo "I am PY2!"
# py3.sh
echo "I am PY3!"
$ [bazel 0.24 RC] run :foo
[...]
I am PY2!
 
$ [bazel 0.24 RC] run :foo --python_version=PY3
[...]
I am PY3!
 
# Extra flag needed to pass validation check but otherwise unrelated
$ [bazel 0.24 RC] run :foo --incompatible_py3_is_default --incompatible_allow_python_version_transitions
[...]
I am PY2!
@brandjon 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
@brandjon brandjon self-assigned this 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
@brandjon
Copy link
Member Author

brandjon commented Mar 4, 2019

As per discussion in #6968, this issue can be closed since the code changes are merged in master.

@brandjon brandjon closed this as completed Mar 4, 2019
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
P1 I'll work on this now. (Assignee required) team-Rules-Python Native rules for Python type: bug
Projects
None yet
Development

No branches or pull requests

1 participant