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

[Paul Moore]

On 13 July 2013 18:30, Donald Stufft <donald at stufft.io> wrote:

> On Jul 13, 2013, at 12:59 PM, Brett Cannon <brett at python.org> wrote:
>
> Could we just start to move away from an executable script and start
> promoting rather aggressively -m instead? It truly solves this problem and
> since the results are tied to the Python executable used (i.e. where
> something gets installed) it disambiguates what Python binary pip is going
> to work with (something I have trouble with thanks to Python 2 and 3 both
> being installed and each with their own pip installation). I realize older
> Python versions can't do this (I believe 2.6 and older can't for packages)
> but at least in the situation we are discussing here of bundling pip it's
> not an issue.
>
>
> I find the -m interface ugly as a primary cli api. It's ok for bonus
> functionality (ala json.tool) and debugging utilities (ala SimpleServer)
> but as a developer of user facing tools I don't think I'd ever want to tell
> them that they should use ``python -m`` to execute my tool.
>
> It's also a massive change in functionality from the existing pip
> interface. ``pip install`` is what everyone uses.
>
> The point is more or less moot though unless you're advocating not
> including an executable script at all. Because pip is already able to be
> executed with ``python -m pip`` however I don't believe i've seen anyone
> use that in practice. It also provides the "pip" and "pip-X.Y" commands
> which should probably be normalized to "pip", "pipX", and "pipX.Y".
>

That's the point of "aggressively promote". We'd advocate "python -m pip"
as the primary means of running pip.

I agree it's less convenient for users than having a simple "pip" command,
but there are a number of downsides to "pip" being the primary interface
(note that you can always alias pip to "python -m pip" in your shell - it's
no harder than managing PATH, which is what many people need to do at the
moment).

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).

I assume, perhaps naively, that improving the experience on Windows is just
as key as improving it on Unix. In my view, the key initial userbase for
the new packaging tools will be Windows users wanting access to binary
wheels.

Paul.

PS I actually *do* prefer just having a pip command. It's just that I doubt
I'll get that on Windows, no matter *what* approach people take - I'll have
to "roll my own" solution. Obviously, aliasing "pip" to "python -m pip" is
the easiest, and probably the one I'd choose, but then again, I know what
I'm doing :-) A "normal" Windows user will just say "these instructions are
c**p, there's no pip command" and either have to resort to Google (probably
with a question like "why doesn't Python's packaging work?" which isn't
good PR for us), or give up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/236e2f2d/attachment-0001.html>