[Python-Dev] PEP acceptance and SIGs

[Donald Stufft]

On September 30, 2015 at 9:14:42 PM, Alexander Belopolsky (alexander.belopolsky at 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