On Tue, Nov 10, 2015 at 3:29 PM, James Bennett <ubernost...@gmail.com> wrote: > On Mon, Nov 9, 2015 at 3:41 PM, Chris Barker <chris.bar...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
