[Distutils] The future of invoking pip
robertc at robertcollins.net
Thu Nov 5 20:04:38 EST 2015
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 $@
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
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
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
> 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.
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the Distutils-SIG