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.

And in addition to this we are starting to make use of the Minimal
Version Selection algorithm for the platforms. This in general allows
users to configure the upper platform version for a particular wheel.
This meant that we had to change the semantics of the API a little:

1. Use MVS for each platform platform tag.
2. Make it such that earlier entries are overridden by later ones, i.e.
   ["musllinux_*_x86_64", "musllinux_1_2_x86_64"] is effectively the
   same as just ["musllinux_1_2_x86_64"].

A remaining thing that will be left as a followup for #2747 will be to
figure out how to allow users to ignore certain platform tags.

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.

[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.

[aignas]

OK, this grew a little more than I would have liked but I wanted to improve the docs for the attr to explain the change in behaviour and I thought doing the cleanup now made sense.

I'll leave extra cleanup (e.g. being able to exclude certain version) for a later PR. This should be considered as part of the builder API ticket anyway:

• Allow users making per-wheel changes for the whl filtering (very low priority)
• Allow users excluding very old whl versions.

[rickeylev]

(I was testing to see if gemini can suggest changes to chunks of code that aren't modified or in files not in the PR. Guess it can't. Oh well, good to know.)

[rickeylev]

I think PR description needs to be updated? Otherwise lgtm