Tracking bug for python 2/3 mode issues

[brandjon]

This bug is to index issues related to selecting Python 2 vs Python 3 mode for py_* targets. The goal is to have sane semantics for this mode selection implemented and documented by EoQ4.

See also Andreas's index of Python 3 issues at #1580. That index is broader-scoped; here I'm mainly concerned with inconsistencies and limitations in --force_python and its related attributes default_python_version and srcs_version.

Note that many of these issues are addressed by common work to redesign the Python mode state. This work is tracked by #6583.

• [ ] #4815: Currently when no python runtime is given (--python_top), python targets use the interpreter on the system PATH. This should be "python3" rather than "python" in the case of targets built in PY3 mode.

• [x] #6744: Bazel assumes that /usr/bin/python is Python 2, which isn't always true.

• [x] #1446: You should be able to directly bazel build a py_library with srcs_version="PY3" without having to specify --force_python=PY3.

• [ ] #4504: We should better document output dir behavior for PY2 vs PY3.

• [ ] #1393: 2to3 support is a stub that always fails, we should instead just remove it.

• [x] #6438: Remove a couple deprecated flags.

• [x] #6441: Reset PY2/PY3 mode across data deps.

• [ ] #6442: The python mode behavior isn't documented well.

• [ ] #6443: genrule's tools attr should be able to contain either PY2 or PY3 binaries.

• [ ] #6445: Clean up old values for srcs_version.

• [ ] #6482: PY2/PY3 generated source files can silently clash in runfiles.

• [x] #6501: Action conflicts are possible if select() can observe more than two states for the Python mode.

• [x] #6647: Migrate the default Python version to PY3.

We should also have per-target ability to control the python runtime, but that's part of a separate improvement to have a "py_toolchain" style rule. In the meantime you can use select() on the force_python flag within a py_runtime rule to get different runtimes for PY2 vs PY3 targets. See for instance here.

[cclauss]

~What is status on this one?~ https://github.com/bazelbuild/bazel/labels/P3

[lberki]

@brandjon , I suppose we should just close this since Python 2 support is almost deprecated?

[brandjon]

Downgrading to P4 to get off my issue tracker since I'm no longer maintaining Python rules. CCing @rickeylev as current label owner.

No idea what our stance is on Python 2 support in Bazel, three years out from its deprecation in the wild. That's probably a product management question that goes beyond mere Python rule TLs.

[cclauss]

Python 2 died 1,083 days ago on 1/1/2020. It is history.

[brandjon]

The question is whether all users of Bazel are free from history. Then again, we have LTS now, so I'm sure the need to keep it at head is greatly diminished.

Still, product management, so I won't weigh in. :)

[rickeylev]

As another data point over in rules_python, as of https://github.com/bazelbuild/rules_python/pull/887 (Dec 1, 2022), we started rejecting PY2 values for python_version and srcs_version at the start of and haven't heard any complaints.

[github-actions[bot]]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.