On September 4, 2015 at 10:12:08 PM, Nick Coghlan (ncoghlan@gmail.com) wrote:
On 3 September 2015 at 09:45, Donald Stufft wrote:
On September 1, 2015 at 9:57:50 AM, Daniel Holth (dholth@gmail.com) wrote:
Looks amazing, why don't we merge it.
I think we need to update the PEP or write a new PEP before we add new tags to the implementation.
Right, we're mainly talking about replacing/updating the compatibility tags in PEP 425. The most expedient way to formalise consensus on that would be to just write a replacement PEP and have it take precedence over 425 even for current generation wheel files.
More generally, this an area where I don't think the PEP process is actually working well for us - I think we'd be better off separating the "produced artifact" (i.e. versioned interoperability specifications) from the change management process for those specifications (i.e. the PEP process). That's the way CPython works, after all - the released artifacts are the reference interpreter, the language reference, and the standard library reference, while the PEP process is a way of negotiating major changes to those. PyPI is similar - pypi.python.org and its APIs are the released artifact, the PEPs negotiate changes.
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? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA