fix(pypi): select the lowest available libc version by default

[aignas]

The #3058 PR has subtly changed the default behaviour of
experimental_index_url code path and I think in order to make things
easier by default for our users we should go back to that behaviour.

The selection of the wheels happens in two ways:

1. If the user specifies whl_platform_tags value like
   manylinux_*_x86_64 then we we should just get the lowest available
   versioned wheel. I.e. if manylinux_2_28_x86_64 and
   manylinux_2_32_x86_64 are available, we should prefer the former.
2. If the user specifies whl_platform_tags value like
   manylinux_2_32_x86_64 then we we should get the highest version
   that is lower or equal than the specified one. I.e. if
   manylinux_2_21_x86_64, manylinux_2_28_x86_64 and
   manylinux_2_36_x86_64 are available, we should prefer the
   manylinux_2_28_x86_64 one.

Fixes #3250

[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 refines the PyPI wheel selection mechanism to improve default behavior and user experience. It specifically addresses how whl_platform_tags are interpreted, ensuring that the most appropriate libc versioned wheels are chosen based on whether a wildcard or a specific version is provided, thereby enhancing compatibility and predictability.

Highlights

• PyPI Wheel Selection Logic Refinement: This pull request reverts a subtle change introduced in PR #3058, adjusting the default behavior of PyPI wheel selection to prioritize user-friendliness and compatibility, especially concerning libc versions.
• Wildcard whl_platform_tags Behavior: When whl_platform_tags uses a wildcard (e.g., manylinux_*), the system will now default to selecting the lowest available versioned wheel (e.g., manylinux_2_28_x86_64 over manylinux_2_32_x86_64), ensuring broader compatibility.
• Specific whl_platform_tags Behavior: If whl_platform_tags specifies a particular version (e.g., manylinux_2_32_x86_64), the system will now select the highest available version that is lower than or equal to the specified one (e.g., manylinux_2_28_x86_64 if 2_32 is specified and 2_21, 2_28, 2_36 are available).
• Issue Fix: This pull request directly addresses and fixes issue #3250.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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 correctly adjusts the wheel selection logic to prefer the lowest available libc version by default for wildcard platform tags, which enhances compatibility. For specific version tags, it correctly selects the highest compatible version. The implementation is sound and the accompanying tests validate the new behavior. I have a couple of suggestions to improve the clarity of the changelog and a test comment to ensure they accurately reflect the implemented logic.

[gemini-code-assist]

The description of this change could be clearer. The current wording is a bit difficult to parse and might be ambiguous to users. Consider rephrasing to more directly explain the two selection scenarios (wildcard vs. specific version), similar to the clear explanation in the pull request description.

Suggested change

	* (pypi) We now by default select the highest closest match wheel version if the user is
	specifying a particular version via the `whl_platform_tags` or if any version is matched via
	the `*` token, then we select the lowest available version.
	Fixes [#3250](https://github.com/bazel-contrib/rules_python/issues/3250).
	* (pypi) Changed wheel selection logic for versioned platform tags (like `manylinux`):
	- For wildcards (`*`), the lowest compatible version is selected for max compatibility.
	- For specific versions, the highest compatible version <= the request is selected.
	Fixes [#3250](https://github.com/bazel-contrib/rules_python/issues/3250).

[gemini-code-assist]

This comment appears to be incorrect and contradicts the behavior being tested. The test asserts that for a requested version 1_3, the compatible wheels 1_1 and 1_2 are sorted with 1_2 having the higher priority. This means the logic selects the highest compatible version, not the lowest. The comment should be updated to reflect this.

Suggested change

	# select the one with the lowest version, because of the input to the function
	# select the highest version that is lower than or equal to the requested one

[rickeylev]

+1 on going back to the previous behavior; I do think that's a regression insofar as users are concerned. For glibc, I think it makes sense to select the oldest (i.e most compatible).

That said, I think the glibc=* means oldest; glibc=X means newest <= X semantics seems prone to confusion.

I'm not sure there's any right answer to this problem, though. Minimal version selection is probably one of the better answers. But, if we look at the python package managers, they have various quirks in how they select dependencies (e.g. uv has flags to control oldest/newest selection, uv ignores >= python_version settings, etc). Having a lock file that just answers these questions more directly is again sounding pretty appealing.

[aignas]

I'll switch to the minimum version selection in both cases and will update the docs as part of this fix. it will be less confusing.