[Distutils] The future of invoking pip

[Nathaniel Smith]

On Tue, Nov 10, 2015 at 3:29 PM, James Bennett <ubernostrum at gmail.com> wrote:
> On Mon, Nov 9, 2015 at 3:41 PM, Chris Barker <chris.barker at noaa.gov> wrote:
>>
>> pip is a special case -- for MOST python command line tools, the user does
>> not care which python it is running with -- if it works, it works.
>>
>> the failure case we are trying to address here is when "pip install" works
>> sjtu fine -- it finds and installs the package into the python pip is
>> associated with -- it just doesn't do what the user wants and expects!
>
>
> I still feel like it's just kicking the problem down the line. Switching
> from 'pip install' to 'python -m pip install' doesn't actually solve the
> issue of how easy we've made it for people to create non-functional Python
> installations (non-functional in the sense that they will mysteriously "work
> but not really work"). All this switch does is hand the problem over to the
> *next* tool the user happens to invoke. So "pip is special" doesn't really
> work as a rebuttal, at least to me.

There are lots of ways that Python installations can be broken. As
another example, I helped someone today whose bug report turned out to
boil down to: they used 'pip install' to upgrade a package, and got
upgraded .py files, but somehow their old .pyc files were still around
and in use, so they were still seeing bugs from the old version. The
solution was to manually delete all the .pyc files [1]. No idea how
they managed that, it has nothing to do with this thread, it's just an
example of how infinitely weird installation/configuration problems
get out at the long tail. Python's installed base is large enough that
one-in-a-million cases happen every day...

What's special about pip is that it totally violates DRY: for a
functional python installation, each way of spawning a python
interpreter needs to have a corresponding stub script to spawn pip,
and the shebang line of that stub script has to point to the
corresponding python interpreter. If any part of this complex
assemblage gets out of sync or missing, then your installation is
broken.

(Very few tools have this kind of consistency requirement, because
very few tools are as tightly tied to a single python environment as
pip is -- who cares which virtualenv hg runs out of, it does the same
thing either way. Also, if you do discover that some virtualenv is
missing a script that it should have, then the way to fix that is...
run pip. Kinda a problem if the missing script *is* pip.)

I totally get why people dislike the ergonomics of 'python -m pip',
but we can also acknowledge that it does solve a real technical
problem: it strictly reduces the number of things that can go wrong,
in a tool that's down at the base of the stack.

-n

[1] https://groups.google.com/d/msg/pystatsmodels/KcSzNqDxv-Q/CCim-Tz_BwAJ

-- 
Nathaniel J. Smith -- http://vorpus.org