[Distutils] The future of invoking pip

[Wolfgang Maier]

On 09.11.2015 02:13, Donald Stufft wrote:
> On November 5, 2015 at 4:08:56 PM, Donald Stufft (donald at stufft.io) wrote:
>>
>> Another possible option is to modify pip so that instead of installing into
>> site-packages we instead create an "executable zip file" which is a simple zip
>> file that has all of pip inside of it and a top level __main__.py. Python can
>> directly execute this as if it were installed. We would no longer have any
>> command except for ``pip`` (which is really this executable zip file). This
>> script would default to installing into ``python``, and you can direct it to
>> install into a different python using a (new) flag of ``-p`` or ``--python``
>> where you can specify either a full path or a command that we'll search $PATH
>> for.
>>
>
> I’ve implemented a proof of concept of this which can be found at https://github.com/pypa/pip/pull/3234. It’s quick and dirty so probably will break down in edge cases. I also know it currently doesn’t generate a ``pip.exe`` on Windows, so if someone runs it on Windows they’ll need to execute it as ``python path/to/Scripts/pip``.
>
> I’ve not tested trying to install it via wheel or even installing it via pip, so you’ll want to check out the branch or download a tarball and run ``python setup.py install`` (or you can run ``python setup.py build`` and just execute ``build/script-X.Y/pip``).
>
> You might see errors if you don’t build it in a clean virtual environment. That’s just because I haven’t bothered to try and isolate the build by default yet.
>

 From your comments on the PR:

 > - We could possibly restore python -m pip and import pip with a
 >   sufficiently magical .pth file installed into site-packages.

Something like this should be done.
I like the idea to have just one pip installed, but I really wouldn't 
like python -m pip to disappear.

Something I miss in all the discussions taking place here is the fact 
that python -m pip is the officially documented way of invoking pip at 
https://docs.python.org/3/installing/index.html#basic-usage and it is 
not particularly helpful if that recommendation keeps changing back and 
forth.

I know some people don't like the wordy invocation, but other people 
(including me) use and teach it because it works reliably. Just because 
a pip executable based invocation pattern looks better, I don't think it 
justifies the change.


 > - We could add some short hands inspired by py.exe with things like
 > -2, -3, 3.4, etc that will translate to -ppython2, -ppython3,
 > -ppython3.4, etc.

Sure, but this extra-effort will be needed just to re-enable something 
that is already possible now via py -m pip.

Your .pth file idea makes me wonder whether an alternative solution 
could be to share one regular pip installation between Python versions 
that way.
Basically, ensurepip and get-pip.py could default to installing pip 
(possibly as an executable zip file) into a separate folder and add a 
.pth file to the sys.executable's site-packages. Later invocations of 
ensurepip/get-pip.py through a different Python could then detect 
presence of pip in its folder and simply add the .pth file to the 
current site-packages.

This would solve the issue of having to manage multiple installations of 
pip, but preserve all current usage patterns (invocation as executable, 
python -m pip, import pip).


 > - If we drop say, Python 2.6 and someone wants to install an older
 >   version, we might have to make it possible to override the name or
 >   something (python setup.py install --script-suffix 2.6?) to enable
 >   that particular special case to still work. This would only be
 >   needed really when altinstall'ing multiple Pythons into the same
 >   bin dir when one or more of those Pythons are not supported by the
 >   "main" version of pip you're using.

Yes, but such cases will occur more often as new Python versions are 
released and you drop support for old ones. Effectively, any developer 
who wants to support older versions of Python than the latest pip 
supports will face the problem of explaining users what to do. So 
something really convincing needs to be worked out here.