<div dir="ltr"><div><div><div><div>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:<br><br></div>* 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)<br>
</div>* 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.<br clear="all">
</div></div><div><div><div><div><div>* ensuring that, for Python 3.4, "python3" and "python3.4" are available for command line invocation of Python, even on Windows<br>* 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<br>
</div><div>* ensuring that the bundled pip is able to upgrade/downgrade itself independent of the CPython release cycle<br></div><div>* ensuring that pip is automatically available in virtual environments created with pyvenv<br>
</div><div>* 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<br><br></div><div>Note that there are still open questions to be resolved, which is why an author/champion is needed:<br><br></div><div>* what guidance, if any, should we provide to Linux distro packagers?<br>
</div><div>* 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?<br>
<br></div><div>Cheers,<br></div><div>Nick.<br></div><div><br>-- <br>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia
</div></div></div></div></div></div>