[Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

[Ned Deily]

In article 
<CADiSq7e4zachW4b_NmwEwPwtxG6DavNdC-ZwHAOAJkQ4sa3Qtg at mail.gmail.com>,
 Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 1 Sep 2014 09:23, "Benjamin Peterson" <benjamin at python.org> wrote:
> > On Sun, Aug 31, 2014, at 16:17, Antoine Pitrou wrote:
> > > On Mon, 1 Sep 2014 08:00:14 +1000
> > > Nick Coghlan <ncoghlan at gmail.com> wrote:
> > > >
> > > > That part of the proposal proved to be controversial, so we dropped
> it from
> > > > the original PEP in order to focus on meeting the Python 3.4 specific
> > > > release deadlines. This also had the benefit of working out the kinks
> in
> > > > the bootstrapping processing as part of the Python 3.4 release cycle.
> > > >
> > > > However, we still think we should start providing pip by default to
> Python
> > > > 2.7 users as well, at least as part of the Windows and Mac OS X
> installers.

A much bigger than average +1

> > > I don't agree with this. pip is simply not part of the 2.7 feature set.
> > > If you add pip to a bugfix version, then you have bugfix versions which
> > > are more featureful than others, which makes things more complicated to
> > > explain.
> > 2.7.x has been and will be alive for so long that will already have to
> > explain that sort thing; i.e. PEP 466 and why different bugfix releases
> > support different versions of dependency libraries.

And that is a minor complication compared with the confusion and 
difficulty of trying to explain to users (stuck with 2.7 for the time 
being) of how to install third-party packages on each platform 
(especially Windows) versus the simplicity of the 3.4.x story, thanks to 
ensurepip.  Having pip available as a documented, batteries-included 
tool for all current releases would be a huge usability improvement.
 
> Exactly. LTS is genuinely different from stopping maintenance after the
> next feature release - it requires considering the "stability risk" and
> "user experience improvement" questions separately.
> 
> In this case, the problem is that the Python 2 platform *is* still
> evolving, but the centre of that evolution has moved to PyPI. For "standard
> library only" users, Python 2 stopped evolving back in 2010. For PyPI
> users, by contrast, it's still evolving at a rapid pace.
> 
> For our Python 3 transition story to be coherent, we need to ensure tools
> like six, modernize and future are readily available, while still remaining
> free to evolve independently of the standard library. That means providing
> a package management utility as easily and as painlessly as possible.
> 
> Embracing pip upstream for Python 2 as well as Python 3 also sends a
> powerful signal to redistributors that says "your users are going to need
> this" and makes them do additional work to *avoid* providing it. Some of
> them *will* choose that path, but that becomes a matter for discussion
> between them and their user base, rather than a problem we need to worry
> about upstream.

FTR, I'm willing to backport the pieces I did for 3.4 and I could do the 
ensurepip backport, as well.  I'll leave the Windows installer changes 
for someone else, though.

-- 
 Ned Deily,
 nad at acm.org