<p dir="ltr"><br>
On 16 Sep 2013 20:06, "Antoine Pitrou" <<a href="mailto:antoine@python.org">antoine@python.org</a>> wrote:<br>
><br>
><br>
> Hi,<br>
><br>
> Donald Stufft <donald <at> <a href="http://stufft.io">stufft.io</a>> writes:<br>
> ><br>
> > This is also a matter of starting as we mean to continue: similar to IDLE<br>
> > (see PEP 434), ``getpip`` will be permanently exempted from the "no new<br>
> > features in maintenance releases" restriction, as it will include (and<br>
> > rely on) upgraded versions of ``pip`` even in maintenance releases.<br>
><br>
> This sounds rather weird. If the whole point of ``getpip`` is for people to<br>
> get the latest pip version without it being bundled, the why does ``getpip``<br>
> itself need to be upgraded in maintenance releases?<br>
> (barring bug and compatibility fixes, obviously)</p>
<p dir="ltr">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.</p>
<p dir="ltr">*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.</p>

<p dir="ltr">><br>
> > The reference ``getpip`` implementation includes the ``pip`` CA<br>
> > bundle along with the rest of pip. This means CPython effectively includes<br>
> > a CA bundle that is used solely for ``getpip``.<br>
> ><br>
> > This is considered desirable, as it ensures that ``pip`` will behave the<br>
> > same across all supported versions of Python, even those prior to Python<br>
> > 3.4 that cannot access the system certificate store on Windows.<br>
><br>
> You mean... it ensures that ``getpip`` will behave the same, right?</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
> > Policies & Governance<br>
> > =====================<br>
> ><br>
> > The maintainers of the bundled software and the CPython core team will work<br>
> > together in order to address the needs of both. The bundled software will<br>
> still<br>
> > remain external to CPython and this PEP does not include CPython subsuming the<br>
> > responsibilities or decisions of the bundled software.<br>
><br>
> Ok, to be clear: "bundled software" means the private pip copy, not "getpip"<br>
> itself, right? Otherwise I'm afraid I don't agree :-) Whichever public API is<br>
> exposed by the CPython distribution is certainly within the realm and moral<br>
> responsibility of the CPython core developers.</p>
<p dir="ltr">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).</p>
<p dir="ltr">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).</p>
<p dir="ltr">><br>
> By the way, the parallel with IDLE here is flawed, because IDLE is a very annex<br>
> and secondary piece of software that few people care about (which is why IDLE<br>
> was several times proposed *out* of the stdlib).</p>
<p dir="ltr">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.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> For the rest, +1.<br>
><br>
> Regards<br>
><br>
> Antoine.<br>
><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>