I'd appreciate a "current packaging specs" site which ideally also states how pypa tools support it, since which version.
holger On Fri, Apr 17, 2015 at 16:18 -0400, Nick Coghlan wrote: > 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 | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
