On 6 November 2015 at 10:08, Donald Stufft <don...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
