Ambiguity in PEP 643: case sensitivity

Packaging Standards
1

I couldn’t find anything about case sensitivity in PEP 643. I think it’s implied because the keys in the email format are case insensitive. Most backends use title case for the keys, and lowercase for the entries in Dynamic.

Recently, uv tried to apply a fix to change it’s behavior (to I think the correct one, and the one in packaging): currently, it checks dynamic as case sensitive, meaning that these lines in flash-attn

Dynamic: requires-dist
Requires-Dist: torch
Requires-Dist: einops

were not registering as dynamic, since requries-dist != Requires-Dist (note that the email format that METADATA is based on has case insensitive keys!). This had to be reverted, though the only reason it worked before is wrong.

Basically everything is listed in both in flash-attn! 
Metadata-Version: 2.2
Name: flash_attn
Version: 2.8.3
Summary: Flash Attention: Fast and Memory-Efficient Exact Attention
Home-page: https://github.com/Dao-AILab/flash-attention
Author: Tri Dao
Author-email: tri@tridao.me
Classifier: Programming Language :: Python :: 3
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: Unix
Requires-Python: >=3.9
Description-Content-Type: text/markdown
License-File: LICENSE
License-File: AUTHORS
Requires-Dist: torch
Requires-Dist: einops
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: description-content-type
Dynamic: home-page
Dynamic: requires-dist
Dynamic: requires-python
Dynamic: summary

uv doesn’t allow you to solve (with match-runtime) if Requires-Dist is in Dynamic. But since requires-dist was in Dynamic, and that didn’t match, it was happily solving assuming this (in fact nothing) was dynamic. Changing it caused this to no longer solve because the SDist declares dynamic requires-dist, so it was reverted.

I think the PEP needs to be updated to mention that the entries in Dynamic are case insensitive. If not, it needs to be updated the other way and most build backends need to change the Dynamic key to match the (case insensitive!) email field names.

CC @dstufft @charliermarsh

4 Likes
2

I think in abstract you could argue either way for whether they should be case sensitive or not. Arguably matching the names case sensitively is “correct” because the names are defined that way.

I think that doesn’t really matter though, because I suspect a non zero number of files have been released with the “wrong” casing, and it’s pretty bikeshed-y either way, and treating them as case insensitive is easy (both to implement and to understand) and fixes existing sdists.

So +1 on clarifying the spec that these are case insensitive.

3

I commented on the linked uv issue, but for the record I’ll add my response here:

As the author of PEP 643, I’ll confirm that the intention was that entries in Dynamic should be treated case insensitively. It’s not explicitly mentioned, but the definition says

A string containing the name of another core metadata field

and metadata field names are generally viewed as case insensitive (indeed, the definition for Metadata-Version uses the field name in lower case within its own definition, making it pretty clear that the intention was for field names to be case insensitive).

I’d support a clarification to the core metadata spec, if anyone wants to propose one, which stated explicitly that field names should be treated as case insensitive.

2 Likes