[Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
Hi folks, The recent release of setuptools 8.0 brought with it the migration to the more explicit version handling semantics defined in PEP 440. Some of the feedback on that release showed us that we could really use the equivalent of PEP 411 for interoperability PEPs as well as for standard library modules: a way to say this is well defined enough for us to publish a reference implementation in the default packaging tools, but needs additional user feedback before we consider it completely stable. The reasons for this are mostly pragmatic: the kinds of tweaks we're talking about are small (in this specific case, changing the normalised form when publishing release candidates from 'c' to 'rc' , when installation tools are already required to accept either spelling as valid), but updating hyperlinks, other documentation references, etc means that spinning a full PEP revision just for that change would be excessively expensive in contributor time and energy. So over on distutils-sig, we're currently considering PEP 440 provisional until we're happy with the feedback we're receiving on setuptools 8.x and the upcoming pip 6.0 release. However, I'd be happier if we could communicate that status more explicitly through the PEP process, especially as I think such a capability would be useful more generally as we move towards implementing metadata 2.0 and potentially other enhancements for pip 7+ next year. If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
On 12/17/2014 12:57 PM, Nick Coghlan wrote: If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. We have provisional for modules, it would seem to also make sense for PEPs. A tracker issue would be good. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
On Dec 18, 2014, at 06:57 AM, Nick Coghlan wrote: However, I'd be happier if we could communicate that status more explicitly through the PEP process, especially as I think such a capability would be useful more generally as we move towards implementing metadata 2.0 and potentially other enhancements for pip 7+ next year. If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. Hi Nick. What specific changes do you propose to PEP 1 and/or the PEP process? FWIW, if they are fairly simple, then I think a tracker issue with at least the PEP 1 authors nosied would be fine. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
On 18 December 2014 at 08:10, Barry Warsaw ba...@python.org wrote: On Dec 18, 2014, at 06:57 AM, Nick Coghlan wrote: However, I'd be happier if we could communicate that status more explicitly through the PEP process, especially as I think such a capability would be useful more generally as we move towards implementing metadata 2.0 and potentially other enhancements for pip 7+ next year. If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. Hi Nick. What specific changes do you propose to PEP 1 and/or the PEP process? FWIW, if they are fairly simple, then I think a tracker issue with at least the PEP 1 authors nosied would be fine. Yeah, good point - I'll want a tracker issue regardless to host the Reitveld review. Filed at http://bugs.python.org/issue23077 My current thinking is that for future PEPs relying on PEP 411 to include a provisional API directly in the standard library, the Provisional state would effectively replace the Accepted state: Draft - Provisional (with PEP 411 disclaimer on the implementation) - Final (PEP 411 disclaimer removed) For interoperability standards track PEPs, I'd propose tweaking their flow to allow the use of the Active state, and stop using Accepted/Final entirely: Draft - Provisional - Active (- Superseded) However, looking at that, I'm starting to wonder if the PEPs like WSGI, the database API, the crypto API, and the packaging PEPs should be pulled out into a new PEP category (e.g. Standards Track (Interoperability)) to reflect the fact that they're defining a protocol, not just a particular standard library API. At the moment, we have an odd split where many of those are listed under Other Informational PEPs (together with things like the instructions for doing releases), while the packaging interoperability PEPs are Standards Track PEPs currently listed under Accepted PEPs. I think the next step would be for me to come up with a draft patch, and then if we think it needs a PEP for broader review (which now seems likely to me), we can decide that on the tracker issue. Cheers, Nick. P.S. You'd think I'd have learned my lesson by now when it comes to pulling on the thread that is PEP 1, but apparently not :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
