chore: remove non-toolchain runtime resolution logic.

[gregestren]

Finding the Python runtime via toolchain resolution has been enabled by default for
many years. Toolchains are the preferred mechanism for specifying Python runtime info.
Usage of the non-toolchain ways should be approximately zero, and they'd be considered
unsupported anyways. Hence this is not considered a breaking change.

This PR removes support for

• "If toolchains disabled" logic (--incompatible_use_python_toolchains)
• configuration_field on python_top (--python_top flag)
• _py_interpreter attribute (plumbing for python_top flag)

Work towards #3252.

[gemini-code-assist]

Summary of Changes

Hello @gregestren, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request streamlines the Python runtime resolution mechanism by removing deprecated non-toolchain logic. It eliminates the _py_interpreter attribute and the conditional checks for use_toolchains, ensuring that all Python runtime lookups consistently utilize the established toolchain system. This change aligns the codebase with modern Bazel practices, simplifying maintenance and improving predictability in Python environment setup.

Highlights

• Removal of _py_interpreter attribute: The _py_interpreter attribute, which was previously used for non-toolchain Python resolution, has been completely removed from py_executable.bzl.
• Elimination of non-toolchain resolution logic: The conditional logic that checked ctx.fragments.py.use_toolchains and provided a fallback to python_top (via _py_interpreter) has been removed. The system now exclusively relies on Python toolchains for runtime resolution.
• Simplification of runtime retrieval: The _maybe_get_runtime_from_ctx function is simplified by removing the alternative path for obtaining the Python runtime when toolchains were disabled, streamlining the process to always use toolchains.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request removes outdated non-toolchain resolution logic, which simplifies the codebase significantly. The changes correctly remove the _py_interpreter attribute and the conditional logic that depended on the use_toolchains flag. This is a good cleanup.

I've added one suggestion to improve the readability of the _maybe_get_runtime_from_ctx function by removing a redundant local variable.