On 15 Jul 2013 01:10, "Paul Nasrat" <[email protected]> wrote: > > > > > On 14 July 2013 02:13, Nick Coghlan <[email protected]> wrote: >> >> Based on the recent discussions, I now plan to reject the pip bootstrapping-on-first-invocation approach described in PEP 439 in favour of a new PEP that proposes: >> >> * bundling the latest version of pip with the CPython binary installers for Mac OS X and Windows for all future CPython releases (including maintenance releases) >> * aligns the proposal with the Python 3.4 release schedule by noting that CPython changes must be completed by the first 3.4 beta, while pip changes must be completed by the first 3.4 release candidate. >> * ensuring that, for Python 3.4, "python3" and "python3.4" are available for command line invocation of Python, even on Windows >> * ensuring that the bundled pip, for Python 3.4, ensures "pip", "pip3" and "pip3.4" are available for command line invocation of Python, even on Windows >> * ensuring that the bundled pip is able to upgrade/downgrade itself independent of the CPython release cycle >> * ensuring that pip is automatically available in virtual environments created with pyvenv >> * adding a "get-pip.py" script to Tools/scripts in the CPython repo for bootstrapping the latest pip release from PyPI into custom CPython source builds >> >> Note that there are still open questions to be resolved, which is why an author/champion is needed: > > > I've a bunch of contacts in various distros still - I've not championed a PEP before but I would be happy to take this on.
Thanks, Paul, that sounds great. Once we have something written up I can run it by Fedora's python-devel list, too. Probably the easiest way to get started is to grab the PEP 439 source from https://hg.python.org/peps, file the serial numbers off and edit that into a proposal for bundling pip with the installers rather than using runtime bootstrapping. PEP 1 has more general guidance on the PEP process (although in this case feel free to send updates directly to me for posting). >> >> * what guidance, if any, should we provide to Linux distro packagers? >> >> * how should maintenance updates handle the presence of an existing pip installation? > > > There are various distro packaging specific ways of handling this. Hard requirements, recommends, obsoleting the standalone package and providing it virtually as part of I suspect we'll end up being fairly agnostic on the Linux details, and merely make it clear that at the very least "pip install --user <pkg>" should be readily available. > >> Automatically upgrade older versions to the bundled version, while leaving newer versions alone? Force installation of the bundled version? > > > My personal experience is that forcing the bundled version to OS with strong in-built packaging (Linux, BSD, other *NIX) is likely to meet with some resistance. I can certainly talk with some people, my instinct is it's likely to be only bundle with installers, allow optional install as part of the cPython build which can then be subpackaged/ignored for seperate pip/bundled as distros so desire. Yes, you can take all my bundling comments as relating specifically to the Windows and Mac OS X installers we provide. Cheers, Nick. > > Paul
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
