[Distutils] The future of invoking pip

[Robert Collins]

On 6 November 2015 at 10:08, Donald Stufft <donald at stufft.io> wrote:
...
> One possible solution to the above problems is to try and move away from using
> ``pip``, ``pipX`` and ``pipX.Y`` and instead push people (and possibly
> deprecate ``pip`` &etc) towards using ``python -m pip`` instead. This makes it
> unambigious which python you're modifying and completely removes all of the
> confusion around that. However this too has problems:
>
> * There is a lot of documentation out there in many projects that tell people
>   to use ``pip install ...``, the long tail on getting people moved to this
>   will be very long.

I don't see that as a specific problem. It drags out the deprecation
period is all.

> * It's more to type, 10 more characters on *nix and 6 more characters on
>   Windows which makes it more akward and annoying to use. This is particularly
>   annoying inside of a virtual environment where there isn't really any
>   ambiguity when one is activated.

cat > /usr/bin/pip << EOF
python -m pip $@
EOF

Seriously - isn't the above entirely sufficient?

> * It still has the annoyance around having multiple pip installs all over the
>   place and needing to manage those.

This is a mixed thing. You *need* those installs when pip drops support for 2.6.

> * We still support Python 2.6 which doesn't support executing a package only
>   modules via ``-m``. So we'll break Python 2.6 unless people do
>   ``python -m pip.__main__`` or we move pip/* to _pip/* and make a pip.py which
>   will break things for people using pip as a library (which isn't currently
>   supported).

Or the same wrapper approach can deal with this - as long as there is
a pip.__main__ on all Pythons.

> 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 don't like this because:
 - pip won't be able to be interrogated in the same way as all other
python packages can be
 - the breakage is huge :(.
 - it doesnt' actually solve the windows problem
 - it makes it hard to use pip except via a subprocess - and while its
not supported, it is at least in principle something we could be
working on (and there was interest in that on python-dev the other
month IIRC).

...
> A side conversation here is that pip currently bundles a number of dependencies
> inside of itself because it can't really have any dependencies. This works
> fine but it's a bit of an annoyance to maintain. The larger problem is that a
> number of downstreams don't like this and have attempted to route around it to
> varying degrees of success. One benefit of the third option is that we can
> remove the need to directly copy the bundled libraries into the pip source code
> and we can install just bundle it inside the built zip file.

Well, we could do that today - only bundle in get-pip.py, have
installed copies have dependencies.

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud