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

[Donald Stufft]

On Aug 19, 2013, at 4:44 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> 
> On 19 August 2013 20:47, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> > 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").
> 
> Have we resolved the "unfortunate importability of scripts" issue?
> 
> Only in the sense that exe wrappers have (once again) proved to be the only really good solution. I promise I *will* write up the discussion so we can stop having it. But I'm not promising anything before 2018 ;-)
> 
> But while there's a technique for implementing self-replacing exes, I don't know if anyone has actually implemented it yet (hence my reservation that we may need to suggest python -m pip to upgrade itself).
> 
> > 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.
> 
> I think this is vital to allow use to manage future changes effectively. I'm
> not sure exactly how the bundling implementation is supposed to work, but in
> my view user programs should not be able to import pip, pkg_resources,
> setuptools etc. from the bundled locations - only from site-packages if they
> have actually been installed there. The interface you're describing should
> be at a CLI level only.
> 
> I don't think that's anyone's current plan (and I don't actually think it's necessary, either).
> 
> I am happy to go with a solution that provides a guaranteed command line interface, documented in a pep and preferably also in the Python docs. That CLI will be couched in terms of a "pip" command - any future contenders will have to be renamed to match the contract, but I see that as an essential aspect of "blessing" the pip command (not the project, just the command) as the Python installer.
> 
> Under the hood, we can happily admit that *currently* the functionality is provided by installing the pip distribution. But if you use anything outside of the CLI in the PEP (whether it's additional pip commands or flags to existing commands not mentioned in the PEP, or if you import pip directly) then you accept that you rely on pip and so work to their release management and compatibility practices, not Python's, *and* you accept that should an alternative project be selected to replace pip, you will no longer have access to those features unless you manually install the pip project (assuming pip still exists at such a time, and supports installing side by side with its successor).
> 
> Hiding the internal implementation is extra effort for little reward, if we take the "consenting adults" view of people using undocumented details.
> 
> Paul
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

My current draft explicitly ensures that the end result is the same as if someone installed pip manually. There will be no importable pip from the standard library.

It also specifically excludes pip from the backwards compat and other governance related issues of CPython.

This is an outdated draft, it needs updated which once I have time in the next few days i'll update it and post it but this is my draft https://github.com/dstufft/peps/blob/master/pip-bundling.rst

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130819/4b520041/attachment.html>
-------------- 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/4b520041/attachment.sig>