On 16 Sep 2013 20:06, "Antoine Pitrou" <firstname.lastname@example.org> wrote:
> 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)
Because getpip contains a complete private copy of pip that it installs in the "--no-download" case and otherwise uses to download the latest version.
*Technically* you could lock down the getpip shim to prevent feature additions, but I don't see the point in introducing cross-version inconsistencies in maintained versions if we decide the shim should expose more pip features.
> > 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?
Both, really. The behaviour of getpip and the behaviour of a "--no-download" pip bootstrap will be the same, since they use the same software.
> > 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
> > 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.
getpip delegates to the included private copy of pip for the installation process, so it may gain new features in maintenance releases (e.g. signature validation if we get a TUF based system working).
This means I'm OK with requiring no backwards incompatible changes to getpip in maintenance releases, I'm not OK with disallowing feature additions (hence the comparison to IDLE).
> 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).
If this bundling approach works for pip, it wouldn't surprise me if IDLE migrated to this multi-version bundled application model in 3.5.
> For the rest, +1.
> Distutils-SIG maillist - Distutils-SIG@python.org