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

[Antoine Pitrou]

Nick Coghlan <ncoghlan <at> gmail.com> writes:
> 
> 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.

Well... Cross-version inconsistencies are the reason we have several maintained
versions in the first place.

If you upgrade getpip's functionality in maintenance releases, this means
someone
with Python 2.7.7 won't get the same experience as, e.g., someone with
Python 2.7.6
or 2.7.8. It breaks the expectation that maintenance releases are basically
substitutable to each other (modulo, of course, bug fixes). It also makes
support
more complicated for the various Python communities ("wait, which 2.7 version
do you have? then your getpip doesn't have that option, you must instead do this
and that...").

It will probably also make Python maintenance more difficult for distributors
(e.g. Linux distros) which commit to API stability between bugfix versions.

Regards

Antoine.