PEP acceptance and SIGs
It has been my understanding that some PEPs may be discussed on specialized mailings lists, but a notice would be given on python-dev prior to any acceptance. I have recently received a notification that since PEP 470 has been accepted, I can no longer use external hosting for one of the packages that I published on PyPI. The PEP refers to a notice [1] posted on distutils-sig, but I cannot find any discussion of PEP 470 on either python-dev or python-ideas. [1]: https://mail.python.org/pipermail/distutils-sig/2015-September/026789.html
On September 30, 2015 at 8:20:53 PM, Alexander Belopolsky (alexander.belopolsky@gmail.com) wrote:
It has been my understanding that some PEPs may be discussed on specialized mailings lists, but a notice would be given on python-dev prior to any acceptance.
I don’t see any requirement to post PEPs to python-dev if they have a Discussions-To header in PEP 1. I don’t really think it makes sense in this case either tbh, PyPI, pip, and setuptools are not under python-dev’s banner. We use PEPs because they are a convenient way to manage change (and we’ve even discussed recently not using PEPs for packaging things that don’t have anything to do with the standard library and moving to a more lightweight process more akin to the Rust RFC process for various reasons). ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft <donald@stufft.io> wrote:
I don’t see any requirement to post PEPs to python-dev if they have a
Discussions-To header in PEP 1. When I faced a similar situation with PEP 495, Guido's advise was "I think that a courtesy message to python-dev is appropriate, with a link to the PEP and an invitation to discuss its merits on datetime-sig." [1] Maybe it is time to clarify that in PEP 1.
I don’t really think it makes sense in this case either tbh, PyPI, pip, and setuptools are not under python-dev’s banner.
Given that ensurepip is part of stdlib, I am not sure this is an accurate statement. Even if it was, did you make any effort to discuss the proposal outside of a small group subscribed to distutils ML? My main issue with PEP 470 is that it came shortly after PEP 438 and replaced it. PEP 438 created a solution that was not very convenient, but possible to implement. With PEP 470, you are punishing the developers who took your advise and created verified external distribution assuming that it would remain available for a foreseeable future. By your own count, [2] 59 projects implemented PEP 438 verification in two years since the PEP was published. You compare that to 931 that remain vulnerable and conclude that the solution did not work. Given that information about PEP 438 features was very thinly disseminated, I think 59 is a large number and it would be appropriate to involve the developers of those packages in the discussion that led to PEP 470. [1]: https://mail.python.org/pipermail/datetime-sig/2015-August/000262.html [2]: https://www.python.org/dev/peps/pep-0470/#impact
On Sep 30, 2015, at 09:14 PM, Alexander Belopolsky wrote:
When I faced a similar situation with PEP 495, Guido's advise was "I think that a courtesy message to python-dev is appropriate, with a link to the PEP and an invitation to discuss its merits on datetime-sig." [1]
Certainly Discussions-To PEPs can be discussed and resolved on mailing lists other than python-dev, and the Resolution header must be set to the URL of the message in that other list that resolves the PEP. A courtesy email to python-dev should go out for all such PEPs, both before resolution (e.g. "hey we're discussing PEP 4000 over on py-in-the-sky-thon@python.org") and after. I do think Standards-Track PEPs (i.e. those that change the language or stdlib) must be discussed and/or posted on python-dev prior to resolution. Cheers, -Barry
On September 30, 2015 at 9:14:42 PM, Alexander Belopolsky (alexander.belopolsky@gmail.com) wrote:
On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft wrote:
I don’t see any requirement to post PEPs to python-dev if they have a
Discussions-To header in PEP 1.
When I faced a similar situation with PEP 495, Guido's advise was "I think that a courtesy message to python-dev is appropriate, with a link to the PEP and an invitation to discuss its merits on datetime-sig." [1]
Maybe it is time to clarify that in PEP 1.
An obvious difference is that PEP 495 modifies the standard library and PEP 470 does not (nor do most of the packaging related PEPs, the one that did was discussed on python-dev).
I don’t really think it makes sense in this case either tbh, PyPI, pip, and setuptools are not under python-dev’s banner.
Given that ensurepip is part of stdlib, I am not sure this is an accurate statement.
PEP 453 states: The bootstrapped software will still remain external to CPython and this PEP does not include CPython subsuming the development responsibilities or design decisions of the bootstrapped software. It was an explicit decision in PEP 453 that these projects still remain independent precisely for this reason.
Even if it was, did you make any effort to discuss the proposal outside of a small group subscribed to distutils ML?
Did I personally? No. The discussion that started PEP 470 actually started on python-dev over a year ago and moved to distutils-sig because people told us to take the packaging stuff off python-dev. However, since it was a PEP, all CPython core developers should have gotten notifications for every modification to the text via the python-checkins mailing list, which all Cpython core developers are expected to be subscribed to. In addition to that, it was also posted as an article to LWN towards the begining of the discussion around it [1]. I don't think it's unreasonable to say that if you want a say in how things are changed, then you should be subscribed to the location where changes get discussed, in this case, distutils-sig.
My main issue with PEP 470 is that it came shortly after PEP 438 and replaced it. PEP 438 created a solution that was not very convenient, but possible to implement. With PEP 470, you are punishing the developers who took your advise and created verified external distribution assuming that it would remain available for a foreseeable future. By your own count, [2] 59 projects implemented PEP 438 verification in two years since the PEP was published. You compare that to 931 that remain vulnerable and conclude that the solution did not work. Given that information about PEP 438 features was very thinly disseminated, I think 59 is a large number and it would be appropriate to involve the developers of those packages in the discussion that led to PEP 470.
Two years is not a short amount of time in the current pace of Python's packaging evolution. Honestly though, we tried PEP 438 and the end result was pip's users were regularly confused. In hindsight, PEP 438 was not a very good PEP. It was impossible to implement in a way that wasn't massively confusing to end users and indeed, our issue tracker, and my personal email, and IRC got fairly regular complaints from end users due to the confusing state that PEP 438 left us in. With my pip core developer hat on, I decided that it was no longer tennable and I fully planned to implement something to replace PEP 438 regardless of if there was a PEP to back it or not (and as an external project, pip is not bound to follow any PEP, our unofficial policy is to attempt to follow all PEPs unless they are harmful or useless). However I decided that it would be a better overall outcome if PEP 438 was replaced with something that didn't have the problems of PEP 438 and to give folks who cared enough to "show up" to discuss it to have a chance to weigh in on it. I should also mention that it wasn't 59 projects implemented PEP 438 in two years, PEP 438 was explicitly implemented in a way that matched the way that a few projects were already using to get verified downloads. If my memory is correct, there were ~30 some projects that already had PEP 438 compliant URLs so realistically, only ~20 some projects willfully and knowingly took advantage of PEP 438, the rest were just left overs from before. Of those ~20, a handful of them were small projects that were utilities to make PEP 438 easier which aren't really relevant when discussing if PEP 438 was successful or not.
[1]: https://mail.python.org/pipermail/datetime-sig/2015-August/000262.html [2]: https://www.python.org/dev/peps/pep-0470/#impact
[1]: https://lwn.net/Articles/599793/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 1 October 2015 at 10:19, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
It has been my understanding that some PEPs may be discussed on specialized mailings lists, but a notice would be given on python-dev prior to any acceptance.
No, that only applies for changes that actually impact the reference interpreter or the standard library - those still need to be discussed and approved on python-dev. For changes that are wholly decoupled from the reference interpreter (like PyPI behavioural changes), the delegation of authority to the relevant SIG is more complete: ================= PEP review and resolution may also occur on a list other than python-dev (for example, distutils-sig for packaging related PEPs that don't immediately affect the standard library). In this case, the "Discussions-To" heading in the PEP will identify the appropriate alternative list where discussion, review and pronouncement on the PEP will occur. ================= (From https://www.python.org/dev/peps/pep-0001/#pep-review-resolution ) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Alexander Belopolsky -
Barry Warsaw -
Donald Stufft -
Nick Coghlan