On 5 September 2015 at 12:14, Donald Stufft wrote:
On September 4, 2015 at 10:12:08 PM, Nick Coghlan (ncoghlan at gmail.com) wrote:
It's only the interoperability specs where we currently follow the RFC
model of having the same document describe both the end result *and*
the rationale for changes from the previous version, and I mostly find
it to be a pain.
I'm not sure that I follow what you?re saying here, can you describe what your
ideal situation would look like?

1. We add a new section to packaging.python.org for "Specifications".
The specification sections of approved PEPs (compatibility tags, wheel
format, version specifiers, dist-info directories) get added there.
API specifications for index servers may also be added there.

2. Interoperability PEPs become proposals for new packaging.python.org
specifications or changes to existing specifications, rather than
specifications in their own right.

3. Each specification has a "version history" section at the bottom,
which links to the PEPs that drove each update.

This way, the PEPs can focus on transition plans, backwards
compatibility constraints, and the rationale for particular changes,
etc, but folks wanting "just the current spec, thanks" can look at the
latest version on packaging.python.org without worrying about the

It also means that the specs themselves (whether additions or updates)
can be prepared as packaging.python.org PRs.


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

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase