Improve UX for abi3 binary wheels

[tiran]

What's the problem this feature will solve?
Warehouse shows Python version: cp36 for a cp36-abi3 binary wheel. This is confusing for users that are not familiar with abi3 wheels. An cp36-abi3 wheel works with any version of CPython >= 3.6,<4.0.

Describe the solution you'd like
Could you please add an indication that ab3 wheels work with any version equal or greater the Python version tag? Something like >= cp36 instead off cp36 would do the trick. If you want to go for the extra mile, then you could add a tooltip that explains what abi3 wheels are and that users need a recent version of pip to install them.

Additional context
The PyCA cryptography gets regular bug reports by users who are unable to install abi3 wheels due to outdated pip, for example pyca/cryptography#6548, pyca/cryptography#6451, pyca/cryptography#6454.

[di]

A bit of extra context here: Right now, the only bit of metadata PyPI extracts from built distributions (including wheels) is the Python version. We don't currently extract or store the ABI tags (or platform tags).

For wheels, this could be inferred from the filename (along with the platform tags as well) but we would need to add a mechanism for doing this, as well as turning a set of tags like ("cp36", "abi3") into a human readable string like "CPython >= 3.6, <4.0".

[alex]

This remains an active issue for us, with users inadvertently downloading PyPy wheels.

What can I do to contribute to moving this forward with clearer human-readable labeling?

[di]

Here's a bit more descriptive list of steps, roughly:

1. extract the tags from the wheel on upload and store them, probably from the filename, probably with packaging.utils.parse_wheel_filename (Here's where we store the python version on the File object currently). We might be able to make this a property on File and not a database column given that File.filename already exists, depends on what we need to do with that field.
   • Adding a proper column will require a database migration, but will make it better if we ever want to query based on this field, or not have to recompute step 2 every time we render for some reason. This will also need to do a data-migration for backfilling the column for old releases
   • Adding a property that derives from File.filename means we won't have to do any migrations. Probably the best short-term option?
2. Find a way to turn the tags into something human-readable, that covers all possible tags. I'm not aware of anything that does this that already exists. Maybe this is just a straightforward function?
3. Display this in the UI when listing artifacts for a release. (Here's where that gets rendered for the Python version).

Optional fourth step: help get #15087 across the finish line? Or at very least, let us know what you think about it there (especially given that the current draft includes an "ABI" dropdown). I suspect being able to filter the long list of built distributions that cryptography supports will also help with user errors here.

[alex]

Ok, I've started working on this -- I think doing it in memory, no DB column, should be fine. 99% of the work is going to be building a robust function to take wheel tags and turn them into something human readable.

Is there a good way to get a dataset of every filename on PyPI to ensure it doesn't crash on any inputs?

[di]

Is there a good way to get a dataset of every filename on PyPI to ensure it doesn't crash on any inputs?

Here you go (split to get around GitHub's file size limits):

• filenames_part_a.txt.tar.gz
• filenames_part_b.txt.tar.gz

[alex]

Thanks. It's a little rough, but here's a basic approach for turning wheel filenames back into tags: https://gist.github.com/alex/98ae99a45584c76f6e850a72110e8ba8

Does this look basically reasonable? If so, I can clean it up and get it turned into a PR.

[di]

Looks OK to me!

[alex]

Great. Will aim to convert it into a PR. Probably tomorrow.

…

On Thu, Mar 14, 2024 at 4:29 PM Dustin Ingram ***@***.***> wrote: Looks OK to me! — Reply to this email directly, view it on GitHub <#10308 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBFUANTFKFB6AQKMPDTYYICDPAVCNFSM5HMAAESKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJZHA2DCMJSGY2Q> . You are receiving this because you commented.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[webknjaz]

Is this a duplicate of #9066?