On Jul 13, 2013, at 1:55 PM, Paul Moore <p.f.mo...@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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to