Splitting out the packaging PEPs, on the PEP site

[CAM-Gerlach]

@ncoghlan

One thing that does make Packaging PEPs genuinely different is that they’re covered by standing delegations from the Steering Council (formerly from Guido back when he was still BDFL). The other potential topics kicked around earlier in the thread don’t have that level of process separation.

Indeed, and a Track header would reflect that, and allow making that more clear in PEP 1. Of course, this does mean we would want SC assent to the overall idea, beyond just being a display/backend change.

@ncoghlan

PEP 1 doesn’t spell out where those delegations are to be recorded, just that they will be recorded and published. The current location of that record is the SC GitHub repo: steering-council/standing-delegations.md at main · python/steering-council · GitHub

We could explicitly link that in PEP 1, since I don’t imagine it is expected to change too often.

@ncoghlan

As far as display goes, something I’ve been contemplating is that rather than trying to change PEP 0 itself, we could instead emit separate track specific pages for the standards track PEPs. So if you wanted to look at only packaging PEPs, you would go to https://peps.python.org/track/packaging/, while the default track might use “Python” as its implied name and be found at https://peps.python.org/track/python/

UI/UX wise, that would be a lot cleaner and less disruptive solution than trying to add a bunch more headings on the PEP 0 page, and not require bikeshedding over any necessary frontend decisions, since it could just use the format of the existing PEP 0 (and not need to modify the same, aside from adding links to the track subpages).

From a technical perspective, it would only require a relatively low number and complexity of changes to the existing generation code ^[1] and would fit well with the existing architecture without being hacky or disruptive. All told, it would be a few dozen lines of code/text and, combined with the tweaks to add, parse and validate the track header, is something I could probably knock out in a few hours once consensus was reached.

It also shouldn’t have any meaningful performance impact, since the PEPs would only be read and parsed once (by far the most intensive part of the process), and only the actual writing out of the indices would be needed.

@ncoghlan

That would then scale reasonably well if further tracks were defined (e.g. a “CPython” track for PEPs that change CPython without also changing the language, or a dedicated “Typing” track).

In fact, it should scale seamlessly to multiple tracks, as adding a new track name would be a only require changing a couple lines in the code (adding the name to a list of valid tracks in constants.py and the pre-commit config, and optionally a custom intro paragraph if it was desired to describe the particulars of the track more specifically), while not affecting existing pages.

---

1. add the header to those parsed in parser.PEP.__init__; filter the PEPs by track and feed them to the PEP generation and writing code in a loop in pep_index_generator.create_pep_zero, plus modifying the filepath generation logic accordingly; and tweaking writer.PEPZeroWriter.write_pep0 to accept a track arg that controls using an appropriately modified intro paragraph ↩︎