[Distutils] Idea: move accepted interoperability specifications to packaging.python.org

[Nick Coghlan]

Daniel's started work on a new revision of the wheel specification,
and it's crystallised a concern for me that's been building for a
while: the Python Enhancement Proposal process is fundamentally a
*change management* process and fundamentally ill-suited to acting as
a *hosting service* for the resulting reference documentation.

This is why we're seeing awkward splits like the one I have in PEP
440, where the specification itself is up top, with the rationale for
changes below, and the large amounts of supporting material in PEP
426, where the specification is mixed in with a lot of background and
rationale that isn't relevant if you just want the technical details
of the latest version of the format.

It also creates a problem where links to PEP based reference documents
are fundamentally unstable - when we define a new version of the wheel
format in a new PEP then folks are going to have to follow the daisy
chain from PEP 427 through to the new PEP, rather than having a stable
link that automatically presents the latest version of the format,
perhaps with archived copies of the old version readily available.

I think I see a way to resolve this, and I believe it should be fairly
straightforward: we could create a "specifications" section on
packaging.python.org, and as we next revise them, we start migrating
the specs themselves out of the PEP system and into
packaging.python.org. This would be akin to the change in the Python
3.3, where the specification of the way the import system worked
finally moved from PEP 302 into the language reference.

Under that model, the wheel 2.0 would be specifically focused on
describing and justifying the *changes* between 1.0 and 2.0, but the
final spec itself would be a standalone document living on
packaging.python.org, and prominently linked to from both PEP 427
(which it would Supersede) and from the new PEP.

This approach also gives a much nicer model for fixing typos in the
specifications - those would just be ordinary GitHub PR's on the
packaging.python.org repo, rather than needing to update the PEPs
repo.

Thoughts?

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia