On 9 November 2015 at 11:27, James Bennett <ubernost...@gmail.com> wrote: > I agree with this, and with the feeling that we're just kicking the failure > down the line: if someone doesn't know what Python is being invoked by > 'pip', they likely will have the same problem with other tools, too, and > ultimately the ability to run Python scripts directly and without having to > do hackery with supporting/requiring 'python -m' or similar is too useful > and commonly used. So faced with either (essentially) forcing a trend of > every command-line tool having to be invoked with 'python -m', or requiring > people with complex multi-Python installations to be more careful, I choose > the "be more careful" option (i.e., I would strenuously resist changing > Django's admin script to "python -m django" if this were proposed to Django > today).
This is pretty much why I said earlier that this isn't really a pip issue. It applies just as much to Django, to pydoc, etc. I'm concerned that what is happening at the moment is that every project implements its own workaround for the issues with wrapper commands and PATH. Either that or most projects simply ignore the issue (after all, 99% of projects aren't installed and used in quite as many of a user's Python installations as pip is). The one thing that *is* special about pip is that it actually *modifies* the Python installation it runs under. So running pip with the "wrong" Python makes persistent changes somewhere you weren't expecting. Whereas running the wrong Django presumably just fires up a website you weren't expecting, which is easily fixed. That makes the issues with wrapper commands and PATH more pressing for pip than for other projects. (But I suspect, for example, that IPython may well encounter similar issues, if I run the "wrong" IPython wrapper it could start up my notebook using the wrong Python interpreter.) I'm no closer to having a good suggestion for a solution here, just trying to point out that by thinking about this from a pip-only perspective we might be missing better solutions that apply from a broader perspective. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
