[Distutils] The future of invoking pip

[Nick Coghlan]

On 10 November 2015 at 09:24, Chris Barker <chris.barker at noaa.gov> wrote:
> As it happens, I am in the middle of a intro class that's using python3.4 or
> 3.5 right now -- and I am telling everyone to do:
>
> python3 -m pip install
>
> Yes, plain old "pip install" is nicer, but only a little bit, and the
> biggest reason we really, really want that to still work is that there are a
> LOT of instructions all over the web telling people to do that -- so really
> too bad if it doesn't work! But the reality is that it often DOESN'T work
> now! and when it doesn't newbies really have no idea why in the heck not!
>
> personally, I think the best approach is to deprecate plain old "pip
> install" -- if it's not there as an option, I expect no one will find it odd
> that to install something for python, you might use python to do that!

Long thread, so I'm picking a semi-random spot to chime in, rather
than replying to every part individually. I think there are a few
different aspects worth considering here:

1. The ergonomics of "pip install X" are really nice, it's by far the
most common instruction given in project documentation, and we're
still in the process of updating documentation to recommend it over
"easy_install X" (or sometimes even over running "./setup.py install"
directly). We *want* it to be the right answer for installing Python
packages, especially in single-installation scenarios.


2. There's one particular reason I *didn't* specify it as the default
recommendation in https://docs.python.org/3/installing/: until Python
3.5, the "pip" executable wasn't placed on the PATH on Windows by
default, even if you'd enabled PATH modification when installing
Python (the problem is that the installers for Python 3.3 and 3.4 only
add the directory where CPython itself resides to PATH, but not the
Scripts directory where "pip.exe" ends up, while even earlier versions
didn't offer the option to modify PATH automatically at all)

So that meant "python -m pip" gave me the broadest coverage - it
worked for everything except system level Python 3 installation on
*nix systems.

With the path issue being fixed in Python 3.5, we're now in the
situation where "pip install X" based instructions will work in all of
the following "single installation" scenarios:

- any activated virtual environment (including conda ones)
- Windows Python 3.5+ installations (with PATH modification selected
at install time)
- *nix Python 2 installations (including Mac OS X and Linux)

"pip install X" still doesn't work for system Python 3 installations
on *nix systems - you need "pip3 install X" or "python3 -m pip install
X" there

Windows Python 2 installations require manual PATH modifications
regardless, but it's more common for people to know how to make
"python -m pip install X" work, than it is for them to remember to
also add the "Scripts" directory needed to make "pip install X" work.


3. I've started thinking of pip as a "plugin manager" for Python. This
is mostly a consequence of work, since many of the challenges we face
in dealing with language specific package management systems are akin
to the ones we encounter with the plugin management systems in web
browsers and IDEs like Eclipse. (It also helps to more clearly
differentiate it from conda, which has the much broader role of being
a data analysis environment manager)

The problem with pip in its current form for that role is that it's
installed as a standalone tool, but isn't natively multi-version
aware. Accordingly, the ideas I like the most are the ones that
suggest taking it down the path of the "py" launcher - make it
natively multi-version aware, and have it choose a well-defined
default target version if multiple versions are available.

Longer term, it may even make sense to take the "python" command on
*nix systems in that direction, or, at the very least, make "py" a
cross-platform invocation technique:
https://mail.python.org/pipermail/linux-sig/2015-October/000000.html

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia