PEP 427: Do not escape period in package names

[gaborbernat]

The suggested code and the text contradicated each other, after
discussing this seems the code example was the correct intent and is
what setuptools is doing.

Signed-off-by: Bernát Gábor [email protected]

More discussion at https://discuss.python.org/t/amending-pep-427-and-pep-625-on-package-normalization-rules/17226/2

[CAM-Gerlach]

Particularly since this PEP has already been migrated to the PyPA specifications page, per PEP 1 (PEP-1):

In general, PEPs are no longer substantially modified after they have reached the Accepted, Final, Rejected or Superseded state. Once resolution is reached, a PEP is considered a historical document rather than a living specification. Formal documentation of the expected behavior should be maintained elsewhere, such as the Language Reference for core features, the Library Reference for standard library modules or the PyPA Specifications for packaging.

And the PyPA specification update process:

The preferred approach to handling corrections and clarifications for all recent interoperability specifications is to designate in the PEP that the actively maintained version of the specification is hosted in the [PyPA Specifications]((https://packaging.python.org/en/latest/specifications/) section of the user guide, and the PEP process is used solely to propose and review changes to the specifications, rather than serving as long term interface documentation in their own right.

shouldn't this change be made on the canonical spec instead of this historical PEP?

[gaborbernat]

I think resolving a conflict of text vs example is not really substantial, it's more of a housekeeping job 👍 Users still use the PEP to refer to how things work, so doesn't hurt addressing the conflicting text.

[CAM-Gerlach]

Well, the various other changes since then haven't been backported, except for one, and on #2690 and #2702 we're adding a new. more prominent banner on packaging PEPs migrated to PyPA specs redirecting users to the latter for the canonical spec and to make any updates. Otherwise, we have to maintain two duplicate documents indefinitely, which will (and already have) inevitably drift out of sync.

At minimum, the change should be proposed and implemented first on the actual spec and then backported to the PEP, as the latter is the canonical spec as well as the mandated venue for proposing such updates.

That said, I'm not the final authority on these matters. @brettcannon ?

[pradyunsg]

Last I checked, we want to move all the Packaging specs to packaging.python.org, so if the content is already there, we should update that and not the PEP.

With the admonition we’re going to add (I’ve been wondering if it should be a sticky banner), we’d have this be clearly noted on the document as well.

[gaborbernat]

In that case, we should add some kind of note/banner on these PEPs that note this PEP text is not authoritative and may be out of date. This is to stop people from referencing them.

[CAM-Gerlach]

Just to note, PEP 427 does say, at the top,

but its not as visible as it could be, which is why... 👇

on #2690 and #2702 we're adding a new. more prominent banner on packaging PEPs migrated to PyPA specs redirecting users to the latter for the canonical spec and to make any updates.

and

With the admonition we’re going to add (I’ve been wondering if it should be a sticky banner), we’d have this be clearly noted on the document as well.

😉

This was actually always nominally true for Final PEPs in general, per PEP 1:

In general, PEPs are no longer substantially modified after they have reached the Accepted, Final, Rejected or Superseded state. Once resolution is reached, a PEP is considered a historical document rather than a living specification. Formal documentation of the expected behavior should be maintained elsewhere, such as the Language Reference for core features, the Library Reference for standard library modules or the PyPA Specifications for packaging.

In practice, this isn't entirely true, but things are slowly moving in that direction.

[gaborbernat]

Seems there's no appetite to fix this, so I'll close this for now. Seems the packaging spec is already committed to PEP-503 and there's no appetite to keep . support arround.