refactor: read migrated native flags through a centralized accessor function

[gregestren]

This lets Python logic support either Starlark- or native-defined flags, based on Bazel support:

• Pre-Bazel 9.0: always use native flags
• Bazel 9.0+: use Starlark flags if incompatible change that disables ctx.fragments.py and ctx.fragments.bazel_py is set
• Include a developer override to trigger Starlark versions while testing Starlarkification. Developers enable this by updating .bzl code in their local workspace. This can be removed as soon as Starlarkification is complete

Also check in a Starlark version of --experimental_python_import_all_repositories for testing.

This is a no-op. New flag sources of truth don't take effect without a supporting bazel version that sets appropriate incompatible flags.

Caveats:

• May not work with configuration_field as implemented. We can loosen the incompatible flag lockdown if that's an issue.

For #3252

TODO list

• Add docs to docs/api/rules_python/python/config_settings/index.md for starlarkified flags

[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 introduces a significant architectural change to how Python-related build flags are handled within the Bazel rules. It establishes a centralized accessor function that intelligently determines whether to retrieve flag values from native Bazel fragments or Starlark build settings. This change is essential for future compatibility with Bazel 9.0 and beyond, which will allow disabling native fragments, and provides a clear path for the Starlarkification of existing flags while offering a developer-friendly override for testing.

Highlights

• Centralized Flag Access: Introduced a new function, read_possibly_native_flag, to provide a unified and centralized way to access Python-related build flags, abstracting whether they are defined natively in Bazel fragments or as Starlark build settings.
• Starlarkification Support: The new flag accessor dynamically determines whether to use native or Starlark flag definitions, which is crucial for compatibility with Bazel 9.0+ where native ctx.fragments might be disabled, paving the way for full Starlarkification of flags.
• Developer Override for Testing: A mechanism is included within the read_possibly_native_flag function that allows developers to explicitly force the use of Starlark flag definitions for specific flags, facilitating testing during the transition period.
• New Starlark Flag Definition: A Starlark-defined bool_flag for --experimental_python_import_all_repositories has been added, enabling its use and testing within the new centralized flag access system.
• Refactored Flag Usage: Existing code in py_executable.bzl and py_runtime_pair_rule.bzl has been updated to utilize the new read_possibly_native_flag for various Python-related flags, ensuring consistent and future-proof flag retrieval.

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 introduces a centralized accessor function, read_possibly_native_flag, to handle reading Python-related flags. This change is a great step towards supporting both native and Starlark-defined flags, which will improve compatibility across different Bazel versions. The implementation correctly abstracts away the logic for choosing between native fragments and Starlark build settings. I have one suggestion to improve the maintainability of the new flag definition map.