On Sep 1, 2014, at 2:22 AM, Ned Deily <nad@acm.org> wrote:

In article
<CADiSq7e4zachW4b_NmwEwPwtxG6DavNdC-ZwHAOAJkQ4sa3Qtg@mail.gmail.com>,
Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 Sep 2014 09:23, "Benjamin Peterson" <benjamin@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@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.

Yes this is a major driver. I mean I think I probably have an above average

knowledge of how to bootstrap pip, and if you dump me on a Windows box

I struggle to actually do it the first time around without stumbling around and

doing things in the wrong order and the like. (Getting a compiler toolchain is

worse, but yay for Wheels).

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.