<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 14 July 2013 02:13, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></div></div></div></div></div></div></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>* what guidance, if any, should we provide to Linux distro packagers?</div>

</div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>
</div><div>* how should maintenance updates handle the presence of an existing pip installation? </div></div></div></div></div></div></blockquote><div><br></div><div>There are various distro packaging specific ways of handling this. Hard requirements, recommends, obsoleting the standalone package and providing it virtually as part of </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Automatically upgrade older versions to the bundled version, while leaving newer versions alone?  Force installation of the bundled version?<br>

</div></div></div></div></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Paul </div>
</div></div></div>