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.

• py_binary doesn't automatically pick a Python runtime matching the requested version #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.

• Bazel doesn't recognize that /usr/bin/python is Python 3, not 2. #6744: Bazel assumes that /usr/bin/python is Python 2, which isn't always true.

• py_library enforces Python 2 for some reason #1446: You should be able to directly bazel build a py_library with srcs_version="PY3" without having to specify --force_python=PY3.

• Document effect of Python version on output path #4504: We should better document output dir behavior for PY2 vs PY3.

• Bazel's 2to3 fails with no messages #1393: 2to3 support is a stub that always fails, we should instead just remove it.

• Remove deprecated Python flags #6438: Remove a couple deprecated flags.

• Reset the PY2/PY3 mode along data dependencies #6441: Reset PY2/PY3 mode across data deps.

• Clearly document PY2/PY3 mode #6442: The python mode behavior isn't documented well.

• Support both Python 2 and 3 in tools (i.e. host configuration) #6443: genrule's tools attr should be able to contain either PY2 or PY3 binaries.

• Deprecate extra values for srcs_version. #6445: Clean up old values for srcs_version.

• Py2/3 generated sources clash in runfiles #6482: PY2/PY3 generated source files can silently clash in runfiles.

• select() on the Python mode should only see "PY2" or "PY3" #6501: Action conflicts are possible if select() can observe more than two states for the Python mode.

• Move to Python 3 by default #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? P3 We're not considering working on this, but happy to review a PR. (No assignee)

[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 bazelbuild/rules_python#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]

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.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post @bazelbuild/triage in a comment here and we'll take a look. Thanks!