[Distutils] Expectations on how pip needs to change for Python 3.4

[Donald Stufft]

On Jul 13, 2013, at 1:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> 1. It's not *actually* the case that the command is always "pip". Maybe it's "pip3" if your system makes the default Python be python 2, but you want to use python 3. Maybe you're creating a virtualenv and you haven't activated it yet. In that case a plain "pip" will quietly do the wrong thing (at the moment, I don't install pip in my system python precisely to avoid this issue).
> 2. On Windows, ...\Python34\Scripts is not on PATH by default. Even if python is (as python.exe is in a different directory to the one distutils installs executables in). Again, you can change your own PATH.
> 3. There's a lot of clutter. On Windows, you have 3 executables (pip.exe, pip3.exe and pip3.4.exe) and 3 scripts alongside them. For one command.
> 
> Apart from the first of these, the issues are all Windows ones, and it's reasonable to say "well, fix the Windows setup, then, it's silly". I have some sympathy with that view, but backward compatibility and many, many years of history will make that extremely difficult. Also, some of it may simply not be fixable because people won't agree on the solution (that's been the case in the past).
> 


1. There's no good way to make it so you don't have to modify your command depending on what python you want to install into. In the case of both ``pip`` and ``python -m pip`` the changes a person would need to make is equivalent. They need to add a version number. The virtualenv case I don't see how that's relevant at all because if pip is preinstalled then pip will be available in both the virtualenv and the system environment. So both ``python -m pip`` and ``pip`` will be operating on the system python if you don't have it activated.

2. This sounds like something that needs fixed on Windows. Even if you say ``-m`` for pip then things are still broken by default for any other package on PyPI that installs a script. So this feels like something wrong with Python on windows not wrong with the script approach.

3. I don't really get the clutter argument. Does it *hurt* to have extra files there? I don't think i've ever looked at the directories on my $PATH and gone "wow I wish there was _less_ things in here". Is this an actual problem people have? Even if it was I think user experience trumps this case.

I'm not sure what Brett is exactly advocating for. If he just wants to document it as ``python -m pip`` well whatever. I have absolutely zero faith that method of invocation will ever become popular. Every single piece of documentation that i've ever seen out there for installing things with pip tells people to use ``pip install``. Every developer that I've ever seen out there is using ``pip install``. An explicit command is shorter, easier to type, and already has basically all of the mindshare behind it. People gravitate towards what's easiest and in my opinion ``-m`` is easier only for the folks implementing this, not for the end users.

Even if ``python -m pip`` is documented we still need to handle the CLI case, and I think that following the convention used by most other programs on *Nix and by windows itself of making the commands, "pip", "pipX", and "pipX.Y" makes the most sense.

If Brett is advocating we _remove_ the command line options and expose only the ``python -m pip`` command that I am vehemently against that and in my opinion that makes for a far worst experience than users have now. The very first thing I would do, if it did happen this way, is create a package "pip-sanity" on PyPI that did nothing but restored the commands and then we end up with a similar situation we have now. That people need to run some bullshit before they can start using pip in the way they want to.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/3b43ac76/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/3b43ac76/attachment.pgp>