[Distutils] PEP 453 Round 2 - Explicit bootstrapping of pip in Python installations

Antoine Pitrou antoine at python.org
Mon Sep 16 12:05:16 CEST 2013


Hi,

Donald Stufft <donald <at> stufft.io> writes:
> 
> This is also a matter of starting as we mean to continue: similar to IDLE
> (see PEP 434), ``getpip`` will be permanently exempted from the "no new
> features in maintenance releases" restriction, as it will include (and
> rely on) upgraded versions of ``pip`` even in maintenance releases.

This sounds rather weird. If the whole point of ``getpip`` is for people to
get the latest pip version without it being bundled, the why does ``getpip``
itself need to be upgraded in maintenance releases?
(barring bug and compatibility fixes, obviously)

> The reference ``getpip`` implementation includes the ``pip`` CA
> bundle along with the rest of pip. This means CPython effectively includes
> a CA bundle that is used solely for ``getpip``.
> 
> This is considered desirable, as it ensures that ``pip`` will behave the
> same across all supported versions of Python, even those prior to Python
> 3.4 that cannot access the system certificate store on Windows.

You mean... it ensures that ``getpip`` will behave the same, right?

> Policies & Governance
> =====================
> 
> The maintainers of the bundled software and the CPython core team will work
> together in order to address the needs of both. The bundled software will
still
> remain external to CPython and this PEP does not include CPython subsuming the
> responsibilities or decisions of the bundled software.

Ok, to be clear: "bundled software" means the private pip copy, not "getpip"
itself, right? Otherwise I'm afraid I don't agree :-) Whichever public API is
exposed by the CPython distribution is certainly within the realm and moral
responsibility of the CPython core developers.

By the way, the parallel with IDLE here is flawed, because IDLE is a very annex
and secondary piece of software that few people care about (which is why IDLE
was several times proposed *out* of the stdlib).

For the rest, +1.

Regards

Antoine.




More information about the Distutils-SIG mailing list