<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 July 2013 16:34, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On 14 July 2013 16:19, Noah Kantrowitz <span dir="ltr"><<a href="mailto:noah@coderanger.net" target="_blank">noah@coderanger.net</a>></span> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="im">
On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:<br>

> On 14 July 2013 12:46, Donald Stufft <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>> wrote:<br></div><div class="im">
> Either the existing APIs are moved to a different name, or they get declared stable and pip switches to "internally forked" APIs any time a backwards incompatible change is needed for refactoring purposes (see runpy._run_module_as_main for an example of needing to do this in the standard library). I've had to directly deal with too many issues arising from getting this wrong in the past for me to endorse bundling of a module that doesn't follow this practice with CPython - if introspection indicates an API is public, then it's public and subject to all standard library backwards compatibility guarantees, or else we take the pain *once* and explicitly mark it private by adding a leading underscore rather than leaving it in limbo (contextlib._GeneratorContextManager is a standard library example of the latter approach - it used to lack the leading underscore, suggesting it was a public API when it's really just an implementation detail of contextlib.contextmanager).<br>


><br>
<br>
</div></div><div class="im">Respectfully, I disagree. Pip is not going in to the stdlib, and as such should not be subject to the same API stability policies as the stdlib. If the PyPA team wants to break the API every release, that is their call as the subject matter experts. Pip is not being included as a library at all. What should be subject to compat is the defined command line interface, because pip is a CLI tool. Independently of this discussion I've already been talking to the PyPA team about what they want to consider a stable API, but that is a discussion to be had over in pip-land, not here and not now. This new category of "bundled for your convenience but still external" applications will need new standards, and we should be clear about them for sure, but I think this is going too far and puts undue burden on the PyPA team. Remember the end goal is simply to get an installer in the hands of users easier.<br>

</div></blockquote><div><br></div></div>I would also be fine with a solution where "import pip" issues a warning about API instability if sys.argv[0] indicates the main executable is something other than the pip CLI.<br>
</div></div></blockquote><br></div><div class="gmail_quote">Oops, meant to add a point to <a href="https://github.com/pypa/pip/issues/1052">https://github.com/pypa/pip/issues/1052</a> for that one.<br><br>Cheers,<br>Nick.<br>
</div><br>-- <br>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia
</div></div>