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

[Nick Coghlan]

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

Well, people shouldn't be running getpip manually very often in the first
place.

The one thing I do *not* want to preclude is security improvements in
maintenance releases. Those *may* require visible CLI changes (e.g. a flag
to opt in to signature checking).

End users should then get the enhanced security automatically most of the
time (as the installers and pyvenv pass in the flag), while direct
invocations will remain unaltered (as they *won't* pass the new flag).

The next Python *feature* release would then make the flag opt-out rather
than opt-in.

I'm happy to limit the exception to such security enhancements, though,
rather than allowing free reign for arbitrary getpip changes in maintenance
releases.

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

If the API additions are limited to opt-in security improvements, they can
probably live with it (although, to be honest, while I don't work for the
Platform team, it wouldn't surprise me if Red Hat still left pip and getpip
out of RHEL and only included it in Red Hat Software Collections,
regardless of what our recommendations say).

Cheers,
Nick.

>
> 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/8790636b/attachment.html>