Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
incompatible_py3_is_default: Bazel configures targets for Python 3 by default #7359
It is recommended to enable this flag at the same time as
Bazel currently defaults to Python 2 due to historic reasons, but the community has largely moved on to Python 3. We should fix this before 1.0.
Note: This incompatible change affects the mechanism that Bazel uses to decide whether a target should be built for Python 2 or 3. However, due to #4815, even when a target is built for Python 3 it may still execute under a Python 2 interpreter. See the workaround using
As of 0.24,
For targets that get built in the host configuration, this command can modify their definitions but it will not actually affect the version that they use. If your build has tools in the host configuration that cannot tolerate Python 3, then you can keep the old behavior of using Python 2 for all host configuration targets (across your entire build) by adding
referenced this issue
Feb 28, 2019
Ran a downstream presubmit with this flag and
For TensorFlow it didn't actually run the test because it failed a hardcoded version check, and it's not clear that it uses the bazel under test. Filed bazelbuild/continuous-integration#569 for assistance.
For the other failures I have no idea whether they're legit or not, and will probably rerun the presubmit to deflake.
New results here. [Edit: fixed link to show all results]
As of this post rules_typescript and Bazel itself still have a mac test running.
In any case, this looks good enough that I'm willing to flip both
Well I'm not so sure. There is indeed a rules_docker project in the set of downstream tests that get run. But when I tested another flag
You can test yourself by grabbing Bazel at head, or a 0.24 RC, and passing (at the same time) --incompatible_py3_is_default and --incompatible_py2_outputs_are_suffixed. You can also check the bazel invocation used in my presubmit and see if any test targets that would've identified problems were missing.
This flag is not actually tested on Bazel CI:
Because it relies on
Can we automatically enable
I manually tested this flag with Bazel 0.24.0 and got the following error
This looks like a bug that has already been fixed at HEAD, but it also means we cannot flip this flag for 0.25.0, because users cannot use 0.24.0 for migration.
See the link in my last post -- I ran the Bazel CI using the downstream w/ bazel@head pipeline, on a custom build that flipped all four python-version-related flags (2 introduced in 0.23 and 2 in 0.24, all to be flipped in 0.25) and it was green. So I don't think migration is actually an issue for this change.
The action conflict issue is partially mitigated by turning on
Ran another rerun of downstream at head + flag flips here. It's clean except for Tulsi which is broken at Bazel head, and Bazel's own presubmits are still running as I'm writing this. So I'm pretty comfortable with proceeding with these flips.
Note that I still have to update Bazels own unit tests for the flag flips. (This isn't reflected by the above presubmit since it modified the host blaze, not the blaze under test.)