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.