[Distutils] What does it mean for Python to "bundle pip"?

[Paul Moore]

While debate on PEP 439 has died down, I've been thinking about what it
actually means to end users for Python to bundle pip. If we have an
explicit bootstrapping command like get_pip, how much practical benefit is
there for that to be bundled vs having a well-known location for such a
script (which is more or less what we have now)?

Also, there is the whole question of how much we want to "lock down" what
pip currently provides, as official functionality. (Particularly given the
renewed energy around projects like distlib/distil, etc).

I'd like to propose that as a first step, we agree and document a *user
interface* that will be officially supported going forward. It would be
based on (a subset of) the pip interface, so that a "bundle pip" strategy
is still the immediate way forward, but by standardising the interface
rather than the implementation, we retain the option to change things
behind the scenes if, for example, distil suddenly takes over the world.

Users get the benefit of a properly sanctioned "one true way" to manage
packages. And we reserve enough flexibility that we don't accidentally
accept constraints that are stronger than we'd like and stifle innovation.

To be specific, what I propose is that we agree on the following:

1. Python installations provide a bootstrap command (tentatively "python -m
get_pip", I'm not sure this needs to be directly executable, the -m
interface is probably fine). This command may be a no-op if for example we
opt for full bundling (and it will always be a no-op after the first run).
2. Once bootstrapped, Python will provide a "pip" command (or pip3?)
accessible whenever the "python" command is available (worded this way
because the Windows installer doesn't put "python" on PATH by default).
3. A specific subset of the current pip interface is provided (to be
documented). I'd suggest we need a minimum of pip install, pip list, pip
uninstall, pip install -U (for upgrades). I don't know what proportion of
the rest of the pip API (various options, requirement files, environment
variables and ini files) we want to lock down - I suggest we start minimal
and add items as needed.
4. We may want to add a separate note that "python -m pip" will do the same
as the "pip" command, and may be needed to self-upgrade the pip command
("python -m pip -U pip").

We can note for 3.4 that the pip command will be implemented using the
current pip project, and so all of the other features of pip will be
available, but with the proviso that any interfaces not explicitly
mentioned in the standard documentation may be changed or removed as pip
changes, and are not protected by Python's compatibility rules. That gives
users a reasonable level of stability, while still allowing us the room to
innovate.

Does this sound reasonable? It may be obvious to everyone but me that this
is what we're expecting - or I may even be proposing *more* than people
expect. But I think something along the lines of an "interface over
implementation" definition like this would be reasonable.

If this is a useful proposal and no-one else is already working on
something similar, I'm willing to write this up as a PEP.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130819/01e78ff6/attachment.html>