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

[Nick Coghlan]

On 16 Sep 2013 20:06, "Antoine Pitrou" <antoine at python.org> wrote:
>
>
> 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)

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
> 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.

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.

Cheers,
Nick.

>
> For the rest, +1.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130916/b9cd5775/attachment.html>