fix(pip): set better defaults for the new target_platforms attr

[aignas]

Fixup the default values for the target_platforms so that the
users can actually switch it as per docs.

I have also taken the liberty to update all of the tests to better
reflect how we set things up for legacy and index-url setups. As
it is now, legacy bzlmod whl_library layout is much more similar
to WORKSPACE, which makes the transition easier.

Work towards #2949

[gemini-code-assist]

Summary of Changes

Hello @aignas, 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 focuses on refining the target_platforms configuration within the Bazel build system, particularly for Python-related dependencies and documentation builds. The changes ensure that default platform settings are applied consistently, addressing a 'work in progress' fixup for behavior related to these default values.

Highlights

• Platform Configuration for dev_pip: The dev_pip extension in MODULE.bazel now explicitly defines target_platforms to include both generic OS/architecture and freethreaded variants, ensuring consistent platform setup for Python dependencies.
• Documentation Build Settings: The sphinx_build_binary rule in docs/BUILD.bazel has been updated to include PY_FREETHREADED and set PYTHON_VERSION to '3.14' within its config_settings, affecting how documentation is built.
• Dynamic target_platforms Defaulting: The _pip_parse function in python/private/pypi/hub_builder.bzl now includes revised logic for target_platforms, defaulting to ["{os}_{arch}"] if pip_attr.target_platforms is not provided and default_cross_setup is false, otherwise using an empty list. This clarifies default behavior for platform targeting.

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
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 behavioral fixup for default values related to target_platforms. The core change in python/private/pypi/hub_builder.bzl modifies the logic to default to the host platform ({os}_{arch}) when no target_platforms are specified, which is a more intuitive and safer default than implicitly targeting all platforms. The modifications in MODULE.bazel and docs/BUILD.bazel seem to be test-related changes to support this fixup. My review includes a couple of suggestions focused on improving maintainability and readability.

[gemini-code-assist]

While the logic is correct, this expression is a bit dense and can be hard to parse at a glance. For improved readability and maintainability, consider extracting this logic into a local variable before the _platforms call. This would make the logic for determining the target platforms more explicit.

For example:

default_target_platforms = [] if default_cross_setup else [\"{os}_{arch}\"]
final_target_platforms = pip_attr.target_platforms or default_target_platforms

Then you can pass final_target_platforms to the function call.