[Distutils] The future of invoking pip

[Paul Moore]

On 5 November 2015 at 21:08, Donald Stufft <donald at stufft.io> wrote:
> Thoughts?

The executable zip solution is in principle the best long-term
solution. But the breakage is major, and it pretty much permanently
cuts off any option to support use of pip as a library. That's
probably OK, but we need to understand that fact.

Further downsides to the executable zip approach:

1. We still need an "exe wrapper" on Windows. This can be as simple as
prepending a stub exe to the zip, but we'd need either to maintain
such a stub ourselves or find a supplier of one.
2. The Python 3.5 zipapp module includes support for a .pyz extension
that is registered as a "zipped Python application". But as you noted,
.exe is treated specially in certain places in Windows, and so there
really is no alternative to a "pip.exe" command if we want the
invocation to remain "pip".
3. On Windows, there is no guaranteed location that is on PATH. If we
supply a "pip.exe" how will we ensure it's on the user's PATH? At the
moment we take advantage of the Python installer (and virtualenv
activate scripts) including the Python Scripts directory on PATH. If
pip were an independent executable, we'd need people to manage PATH
themselves.
4. Wouldn't the executable zip still be run with a specific Python,
coded in the wrapper or shebang line? You say it'd install into
"python" by default. But what about on Windows where the py launcher
gets "the default Python" from its ini file, not from what's on PATH?
And to use a different Python, you're potentially talking about "pip
-p C:\Users\xxx\AppData\Local\Programs\Python\Python35\python.exe".
Over my dead body :-)

If I misunderstood, and your proposal is "python pip.zip", then
there's still a problem as the *actual* usage would be "python
C:\Whatever\Path\To\pip.zip" - which is far from user friendly.

Overall I think that "python -m pip" is the best compromise. Users can
write their own wrapper scripts, shell functions or aliases for common
usage. But they probably won't in practice. So there is a lot of pain
for users (not just command line use, every script that does
subprocess.call(['pip', ...]) would need changing).

Sadly, there's no really good solution :-(

It seems to me that the main questions are:

1. Do we want the canonical invocation to remain "pip" or are we
willing to break that? [I'm ambivalent on this, personally, but it's a
significant compatibility break]
2. Do we mind if there's a different command needed to upgrade pip? [I
don't, as long as pip supports *some* command to upgrade itself]
3. Do we want to move away from a pip per Python installation? [For
me, it'd be somewhat convenient, but nonessential, and I suspect some
people would have Python installations or virtualenvs where they want
to have a *different* pip than the default one - so this change might
actually be a regression for them]

Paul