Move to Python 3 by default #6647
Comments
brandjon
added
type: feature request
P2
|
Prioritizing. We want this to be available in --all_incompatible_changes starting in 0.24, probably to be flipped in 0.25. Current plan is as follows:
We want to change the output path naming because it'd be weird if targets aren't put in |
brandjon
added
P1
|
I should say, |
|
So on further reflection, I think it is indeed problematic to indefinitely allow customizing the default version via a flag, since (as I pointed out above) it makes it hard to compose different repos in one build. I'm considering scrapping |
…t`'s default version When this flag is enabled, `py_binary` and `py_test` targets that do not specify a version (by setting the `python_version` attribute, or its deprecated alias `default_python_version`) will default to `PY3` instead of `PY2`. In addition, the host configuration will use `PY3`, unless `--host_force_python=PY2` is set to override it. The flag requires the new version semantics (`--incompatible_allow_python_version_transitions=true`), and will fail the build if it is not set. The flag is implemented by eliminating PythonVersion#DEFAULT_TARGET_VALUE and replacing it with an accessor PythonOptions#getDefaultPythonVersion. For the case of rule transition factories in rule definitions, which previously relied on DEFAULT_TARGET_VALUE and which do not have access to a configuration, they are updated to instead pass a callback function that retrieves the default version from the configuration at the time of the transition. Work toward #6647, #7359. RELNOTES[INC]: Added --incompatible_py3_is_default to test switching the default Python version to PY3 for py_binary/py_test targets that do not specify a version. See #7359. PiperOrigin-RevId: 232939284
This adds --incompatible_py2_outputs_are_suffixed, which makes it so Python 2 targets get built under an output root with the "-py2" suffix, and Python 3 targets get built under a root with no additional suffix. This means that the `bazel-bin` symlink contains Python 3 targets instead of Python 2 targets. This goes hand-in-hand with --incompatible_py3_is_default, which controls whether targets get built in the Python 2 or Python 3 configuration by default. Enabling just one flag or the other will cause the majority of targets to get built under an output root other than the one pointed to by `bazel-bin`, which is not very convenient. In general users and scripts are not supposed to care what the exact output path of a target is, but in practice they do, hence why this is an incompatible change. Work toward #6647. See #7593 for migration info. RELNOTES[INC]: Added --incompatible_py2_outputs_are_suffixed, for switching the bazel-bin symlink to point to Python 3 outputs instead of Python 2 outputs. See [#7593](#7593). PiperOrigin-RevId: 236207234
|
According to downstream presubmit results, we'll be able to flip both flags for 0.25. |
Once #6583 is implemented, we'll want to look at switching the default Python version to PY3. The default version is the version used when no version selector attribute is explicitly set on a
py_binaryor via a top-level flag.We can do this change by adding an incompatible flag, e.g.
--incompatible_default_python_version_is_py3.Another possibility is to also add an extra flag,
--default_python_version, that could be either PY2 or PY3 (but with the incompatible flag on it would itself default to PY3). This would allow whole projects to customize the default value indefinitely. I'm not sure whether this is useful. In fact I think it could be harmful, because it means the semantics of Python targets in deep dependencies (including in external repos) could change based on the top-level flag.The text was updated successfully, but these errors were encountered: