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

[Donald Stufft]

I'm only briefly checking my email before going back to sleep but just thought I'd mention I have a successor to PEP439 mostly written and I was planning on finishing it up based on some feedback i'd gotten and publishing it this week.

More specific response when I'm not half asleep.

On Aug 19, 2013, at 7:31 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> 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.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130819/9a2e1e97/attachment.sig>