Provide a table summary view of available wheels per package release

[johnthagen]

What's the problem this feature will solve?

For non pure python, non abi3-wheel packages, it's often challenging to be able to determine if a wheel is available for a given platform and (C)Python version.

Currently, a user has to wade through a long list of wheel file names and decipher their meaning. For example, try to quickly determine which Python versions and platforms are supported by pydantic-core 2.7.0:

• https://pypi.org/project/pydantic-core/2.7.0/#files

Some projects have specific wheels for some CPython versions, but not others. For example, lxml 4.9.3 has macOS universal wheels (i.e., supports ARM) for CPython 3.11 and 3.12 only, but has x86-only wheels for 3.6-3.10.

Tracking down why pip or a workflow tool like Poetry can't resolve a wheel for a specific configuration can be challenging, especially for beginners who aren't familiar with the wheel filename format.

Another problem that this helps solve is to remove one of the uses of the Programming Language :: Python :: 3.x trove classifiers, which some in the community do like using (e.g., it requires a package to do a release just to update the trove classifier when otherwise it might not be needed). This table would make it easy for users of non pure Python, non abi3-wheel packages to quickly see which Python versions have wheels published for, rather than needing to look at the trove classifiers.

Describe the solution you'd like

Display a simple table that summarizes the available wheels for PyPI project releases on their PyPI page. If a project is pure Python and only has a pure Python wheel, this table could be omitted or otherwise simplified to a statement such as "Pure Python" or "All Platforms".

A quick and dirty draft of the idea:

Python Version	win_amd64	macosx_11_0_universal2	manylinux_2_28_x86_64
CPython 3.8	✅	✅	✅
CPython 3.9	✅	✅
PyPy 3.9 7.3	✅

Additional context

This was originally discussed at:

• https://discuss.python.org/t/have-pip-warn-when-installing-for-a-python-version-that-is-not-covered-by-the-trove-classifiers/33326/17?u=johnthagen

@hugovk had some additional ideas, including inverting the rows/columns to make the information flow "down" more than "wide"

• https://discuss.python.org/t/have-pip-warn-when-installing-for-a-python-version-that-is-not-covered-by-the-trove-classifiers/33326/22?u=johnthagen

[johnthagen]

It was also mentioned on Discourse by another user that allowing a user to filter the table by OS/Python version, etc may help a user answer the question if there platform is supported more quickly.

• https://discuss.python.org/t/have-pip-warn-when-installing-for-a-python-version-that-is-not-covered-by-the-trove-classifiers/33326/28

[di]

I like this idea in general (I also find the long list of built distributions hard to parse) but I think this might be challenging because in practice, we'd need to represent this matrix across 3 axes: python version, ABI, and platform/CPU architecture, which doesn't translate well into the 2D table.

It might make more sense to make the list filterable, as discussed in that last thread, so a user could select the subset they are interested in.

[ofek]

What about this? https://ofek.dev/coincurve/install/#wheel

[di]

That still doesn't take the ABI into account, since in that case it's the same as the Python version, but you could be publishing both coincurve-18.0.0-cp37-cp37m-musllinux_1_1_x86_64.whl and coincurve-18.0.0-cp37-abi3-musllinux_1_1_x86_64.whl, an edge case we'd need to handle.

[woodruffw]

Triaging: some incremental improvements related to this were performed with #15606.