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

[Donald Stufft]

> On Sep 1, 2014, at 2:22 AM, Ned Deily <nad at acm.org> wrote:
> 
> In article 
> <CADiSq7e4zachW4b_NmwEwPwtxG6DavNdC-ZwHAOAJkQ4sa3Qtg at mail.gmail.com <mailto:CADiSq7e4zachW4b_NmwEwPwtxG6DavNdC-ZwHAOAJkQ4sa3Qtg at mail.gmail.com>>,
> Nick Coghlan <ncoghlan at gmail.com <mailto: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.

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.

Awesome, I’m of course willing to back port ensure pip itself as well. Truthfully
it shouldn’t be a very difficult backport. It’s only ~200 SLOC or so and the only
real things would be removing a Python3ism here or there.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140901/b00654e7/attachment.html>