Call for PEP author/champion: Bundling pip with CPython installers
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: * what guidance, if any, should we provide to Linux distro packagers? * how should maintenance updates handle the presence of an existing pip installation? Automatically upgrade older versions to the bundled version, while leaving newer versions alone? Force installation of the bundled version? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Jul 14, 2013 at 2:13 AM, Nick Coghlan <ncoghlan@gmail.com> 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: [SNIP] * ensuring that, for Python 3.4, "python3" and "python3.4" are available for command line invocation of Python, even on Windows
Can I ask why this is part of the PEP?
On 15 July 2013 00:28, Brett Cannon <brett@python.org> wrote:
On Sun, Jul 14, 2013 at 2:13 AM, Nick Coghlan <ncoghlan@gmail.com> 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: [SNIP] * ensuring that, for Python 3.4, "python3" and "python3.4" are available for command line invocation of Python, even on Windows
Can I ask why this is part of the PEP?
Mostly because "pip3" makes no sense without it. If we *don't* bring Windows into conformance with the way other platforms handle parallel Python 2 and Python 3 installs, then the PEP should document an explicit rationale for not doing it (the py launcher doesn't count in that regard, since the real purpose of that is to handle shebang lines through file associations, with the direct command line usage as an added bonus). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 14 July 2013 02:13, Nick Coghlan <ncoghlan@gmail.com> 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.
* 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 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. Paul
On 15 Jul 2013 01:10, "Paul Nasrat" <pnasrat@gmail.com> wrote:
On 14 July 2013 02:13, Nick Coghlan <ncoghlan@gmail.com> wrote:
Based on the recent discussions, I now plan to reject the pip
* bundling the latest version of pip with the CPython binary installers
for Mac OS X and Windows for all future CPython releases (including
* aligns the proposal with the Python 3.4 release schedule by noting
bootstrapping-on-first-invocation approach described in PEP 439 in favour of a new PEP that proposes: maintenance releases) 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
On 14 July 2013 07:13, Nick Coghlan <ncoghlan@gmail.com> wrote:
* ensuring that pip is automatically available in virtual environments created with pyvenv
Is the proposal here for pyvenv to download pip or to install a locally stored copy? Using a locally stored copy is what virtualenv does, and I'd prefer it to avoid issues where the user's PC has no internet access (as well as avoiding the need to worry about secure downloads and bundling certs, which was why virtualenv took this route). Paul
On 15 July 2013 21:24, Paul Moore <p.f.moore@gmail.com> wrote:
On 14 July 2013 07:13, Nick Coghlan <ncoghlan@gmail.com> wrote:
* ensuring that pip is automatically available in virtual environments created with pyvenv
Is the proposal here for pyvenv to download pip or to install a locally stored copy? Using a locally stored copy is what virtualenv does, and I'd prefer it to avoid issues where the user's PC has no internet access (as well as avoiding the need to worry about secure downloads and bundling certs, which was why virtualenv took this route).
Using a locally stored copy. I'm also considering a new trick for the import system (in the general vein of *.egg-link files) that would let us achieve that without copying, and perhaps even let us eventually deprecate *.pth files entirely. If that scheme comes to fruition it will be as an independent PEP, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Brett Cannon -
Nick Coghlan -
Paul Moore -
Paul Nasrat