<div dir="ltr"><div class="gmail_extra">On 13 July 2013 13:25, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we need to flip the dependencies so that pip as the installer has all the essential code for installation from PyPI and then setuptools and distlib depend on that pip infrastructure. No need to add anything to the standard library prematurely when we can add it to pip instead.</blockquote>
</div><br>If we do this, I think people will start to expect to be able to code scripts to the pip API. (We've had people ask this on the pip tracker already). If we don't want pip to end up like distutils (with people depending on all sorts of random bits of the internals, because there's no documented API) as a backward-compatibility nightmare, we need to consider how to handle this.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Of course, saying explicitly "only the python -m pip command line interface is stable and supported" may well be enough. But didn't we just say that setuptools and distlib depend on the pip API? So either they have special privileges (presumably because they are under the umbrella of the PyPA) or we can't avoid documenting/supporting some API...</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>I don't believe that pip is currently in a state to offer a solid documented internal API.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
Paul</div></div>