In article <cadisq7e4zachw4b_nmwewpwtxg6davndc-zwhaoajkq4sa3...@mail.gmail.com>, Nick Coghlan <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. > 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, n...@acm.org _______________________________________________ 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
