Yep, exactly, which your PR appears to implement precisely as specified, as far as I can tell.
(Though, to note, the error message added is slightly imprecise, as it can also fire when the name contains only ASCII alphanumeric and [-_.], but the leading and/or trailing characters are the latter rather than the former.)
Fixed, thank you!
At this point I think I’m ready to ask @pf_moore to pronounce on the PEP.
Looking ahead to implementation in the specifications, assuming this PEP is accepted, I’d be happy to help, with your review. In terms of specific steps:
Provides-Extra section would need a fairly modest update to reflect conformance with PEP 508 naming (probably through referring to what’s currently in the Name and Requires-Dist sections) and that the extras names should be normalized via PEP 503 when writing them out, and that normalized names are considered equivalent.OK, I’ll take a look over the next day or two.
… as will Metadata-Version.
I would rephrase that as names should be normalized before comparing them, but yes.
No, we would update the relevant parts of packaging.python.org to call out PEP 685.
Depending on whether Paul accepts the PEP as-is, it’s simply going to require trawling through the specs to find out where extras are mentioned and make sure they are updated appropriately.
Oh yes, of course.
So we’d add PEP 685 to the (growing) list of PEPs mentioned as modifying PEP 503 on the Simple Repository API page linked previously?
Searching for other mentions of extra and extras in the packaging specs and the still-relevant/linked PEPs, these were the others spots I found:
I’m confused. How does PEP 685 modify PEP 503? Simply using the same algorithm as PEP 503, for an additional purpose, isn’t modifying the original PEP…
It doesn’t, I was the one confused—unlike the project name, the extras name doesn’t directly intersect with the simple repository API that PEP 503 describes.
However, it seems we should describe, or at least reference, that when processing dependency specifiers, extras names should be normalized following the algorithm in this PEP (i.e. that in PEP 503), besides just mentioning that that they should be normalized when writing out and reading from core metadata (since tools may interact with dependency specifiers in a number of other contexts).
Therefore, would it make sense to mention and link PEP 685 on the dependency specifiers page, as is currently done for the other relevant/modifying specs on the aforementioned simple repository API page? It might make sense to link PEP 503 as well as the source of the algorithm, as well as explicitly mentioning that names should be normalized following it as well (since right now, that isn’t explicitly stated).
To be honest, I think you’re over-complicating things, but it’s your PR so it’s up to you, ultimately.
Err, well, wouldn’t it be up to @brettcannon as the PEP author?
I thought you were talking about the PR to update the docs to reflect the PEP. My apologies if I misunderstood, but if it’s about the PEP then that’s been submitted for review now, so I don’t expect it to be changed at this point.
Yeah, but as @brettcannon is the author of the PEP motivating these updates, I would defer to his guidance on whether he’d like my help with the PR, and if so on what to update, if he has a preference.
On reflection while reviewing this section of the PEP, I think it could be worded slightly more clearly. To be specific, I think the intent is fine, but the phrasing could be clearer, so I will submit a PR to the PEP which IMO improves the wording. This won’t affect my decision on the PEP, though.
It is with great pleasure that I confirm that PEP 685 is approved. Congratulations to @brettcannon and thanks to everyone who participated in the discussions.
There’s not much else to say on this PEP, it’s a nice, clean and well-focused change that provides clarity on a previously ill-defined aspect of packaging. I’d strongly encourage tools to adopt it as soon as possible.
Hatchling already does as of v0.21.0, in case anyone wants to try it out.
@brettcannon, could you mention the acceptance on the original thread, to notify people who watched it?
[edit: corrected link]
By “original thread”, I assume you mean this one (the link was to @pf_moore 's acceptance message on this thread)?
For those spec pages that are just referring to PEPs currently, yes. I only have so much bandwidth and rewriting all packaging specs that still directly reference PEPs is not a small undertaking.
Thanks so much! I have gone ahead and marked the PEP as accepted. The PEP could jump straight to “final” or wait until we feel enough of the community has adopted it (e.g. packaging).
I have also opened Implement PEP 685 · Issue #526 · pypa/packaging · GitHub against packaging so it can adopt this PEP.
Done!
I did (belatedly) think of one potential backward compat issue with PEP 685 (in particular, having producers write out the normalized form combined with using - instead of _ for the normalization character) to be aware of.
If a package’s metadata is produced with a PEP 685-conforming tool and an extra has a name that includes a _ (or a .), it is written out in its PEP 503-normalized form (with -). If tools consuming that metadata are not PEP 685-aware, i.e. they do not perform PEP 503 normalization on existing user inputs (e.g. a user attempting to install a package with that extra, a requirements.txt specifies it, or a dependent package requires it), then existing working requirement specifiers with the existing non-normalized name will stop working until the consuming tools are updated, or the normalized form of the extras name is specified instead.
This could be avoided by not having metadata producers write out the normalized form of the extras name to the core metadata (or mostly mitigated by choosing _ instead of - as the normalization character, given the latter is much more popular currently), but I’m not sure this is enough of a problem in practice to warrant that, since pip at least (by far the most popular tool in a position to encounter this problem) does appear to already normalize extras names, and to - as well, so either these cases already work, or they already don’t (and in practice, - and producer-side normalization may actually be less problematic for this existing case, the one which originally motivated this PEP). But I just wanted to mention that so others are aware.