[Distutils] The future of invoking pip

[Donald Stufft]

> On Nov 5, 2015, at 5:41 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
>> 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.

I think we can still use the ones we use now, although they might not support a zip file. Afaik they just execute a python script and I guess (hope) that they don't validate that and a zip file can be a "script" too. 

> 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.

I'm my mind we wouldn't be throwing out wheels, we'd just build this zip instead. So our wheels would only contain this executable pip zip as a script (not console entry point) and pip would automatically wrap them with exe on Windows. 

> 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 :-)

I think we could integrate with py on Windows somehow so that we use the same lookup semantics as py does. I don't know enough about Windows and py.exe to know what exactly those are. 

> 
> 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 :-(

Yup :(

> 
> 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]

I'm also somewhat ambivalent by only because I'm just going to add an alias to restore "pip". 

> 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]

I'm not sure if we'd need a different command to upgrade pip. In my head pip is still installed as a Python package. It'll just have non standard build steps. 

> 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]

There wouldn't be anything preventing you from installing multiple versions of pip into an environment as we do today. It just wouldn't be mandatory. 

> 
> Paul