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