[Distutils] Expectations on how pip needs to change for Python 3.4

[Nick Coghlan]

On 14 July 2013 16:19, Noah Kantrowitz <noah at coderanger.net> wrote:

> On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:
> > On 14 July 2013 12:46, Donald Stufft <donald at stufft.io> wrote:
> > 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).
> >
>
> 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.
>

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130714/ffc68c95/attachment.html>