Makes sense! I’m going to update the PEP (via the current open PR) to remove any prescriptions about metadata producers needing to/performing label normalization, and move the standard entirely to the index/consumption layer.
Edit: I’ve updated PEP 753: Updates by woodruffw · Pull Request #4010 · python/peps · GitHub to make label normalization an entirely consumer-side affair.
Thanks for pinging me! We can support these changes in the uv build backend.
Currently, the only place using Home-page and Download-URL is uv publish, which attaches those fields as formdata. I have implemented the normalization changes on top of the build backend branch:
Code changes: Implement build backend metadata by konstin · Pull Request #7901 · astral-sh/uv · GitHub
Docs: Add PEP 753 well-known project urls · astral-sh/uv@c9f6e68 · GitHub
The PEP already looks very complete so I have only some minor comments:
The mechanism for presenting this warning or notification is not specified, since it will vary by index. By way of example, an index may choose to present a warning in the HTTP response to an upload request, or send an email or other notification to the maintainer(s) of the project.
Given then current underspecifiedness of the upload api, I don’t think the http response part is feasible without PEP 694, which specifies its own mechanism for notices.
If a distribution’s metadata contains both sets of fields, the index MAY choose to reject the distribution outright. However, this is NOT RECOMMENDED until a future unspecified major metadata version formally removes support for Home-page and Download-URL.
If we want, we can ban build backends from emitting Home-page and Download-URL in the next minor version, i.e. if you want to write let’s say metadata version 2.4, you must not include those fields. Timing is difficult since there are no “METADATA releases” independent of individual PEPs and PEP 639 is also getting stabilized.
Metadata producers SHOULD emit the normalized form of a user specified label, but MAY choose to emit the un-normalized form so long as it adheres to the existing 32 character constraint.
I’d prefer the clarity of a MUST here.
I could omit it entirely, but this was intended to reflect the current behavior of Warehouse: the current file_upload handling returns a list of (newline-delimited) warnings within the body of the 200 OK response, which twine logs when present.
(I could make it clearer that this isn’t intended to be normative/prescriptive over an upload API, just an example of something that’s already doable with PyPI’s upload contract.)
I would indeed like that, although I already have at least two other PEPs queued up after this so I don’t want to commit to a personal timeline 
.
FWIW the latest changes actually remove the obligation that build backends perform any normalization at all; the PR mentioned above (#4010) changes it so that the consumer side only performs normalization as part of processing/presentation.
I changed that based on @pf_moore and @ncoghlan’s feedback about producer-side normalization potentially modifying the user’s intent too much. But if you feel strongly that the producer-side should also be normalizing here, then I’m happy to revisit it 