> On Sep 1, 2014, at 2:22 AM, Ned Deily <n...@acm.org> wrote: > > In article > <cadisq7e4zachw4b_nmwewpwtxg6davndc-zwhaoajkq4sa3...@mail.gmail.com > <mailto:cadisq7e4zachw4b_nmwewpwtxg6davndc-zwhaoajkq4sa3...@mail.gmail.com>>, > Nick Coghlan <ncogh...@gmail.com <mailto:ncogh...@gmail.com>> wrote: >> On 1 Sep 2014 09:23, "Benjamin Peterson" <benja...@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 <ncogh...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
