Flag: --incompatible_remove_old_python_version_api
Available since: 0.23
Will be flipped in: either 0.24 or 0.25, depending on migration progress
Tracking issue: #6583
Design doc
Corresponding semantic change: #7307

Motivation

With the semantic changes described in #7307, the names default_python_version and --force_python no longer make sense since the Python version is no longer "sticky". Also, select()-ing on "force_python" is dangerous in that it can lead to action conflicts (build failures).

See the design doc for more details.

Change

This prohibits use of the default_python_version attribute and --force_python flag. Users should use the python_version attribute and --python_version flag instead.

The new attribute and flag behave exactly the same as the old. Furthermore, enabling --incompatible_allow_python_version_transitions will have the same effect on the new and old APIs.

Since --force_python is removed, it becomes illegal to select() on "force_python". This is good, because doing so can lead to action conflicts. Users should instead select on @bazel_tools//tools/python:python_version (see here). As a drive-by cleanup, this flag also prevents select()-ing on "host_force_python", though it does not otherwise affect the --host_force_python flag in any way.

Migration

• Rename all occurrences of the attribute default_python_version to python_version. This can be done with a buildozer command such as:

buildozer -k -types 'py_binary,py_test' 'rename default_python_version python_version' //...:*

• Rename all invocations with the flag --force_python=... to instead pass --python_version=....
• Replace uses of select() on "force_python" as per the above. Note that the [...]:python_version dependency goes in the flag_values attribute of a config_setting, not the values attribute.

The new attribute, flag, and select()-able value all currently exist in Bazel 0.23 regardless of whether or not any incompatible flag is enabled. The new attribute and flag take precedence over the old, and the new select()-able gives the correct result in all cases. Therefore, it's safe to migrate incrementally and flip this flag on to confirm you found all uses of the old API.