pip3 : command not found

[Chris Angelico]

On Sun, Nov 6, 2016 at 3:53 AM, Steve D'Aprano
<steve+python at pearwood.info> wrote:
> [1] Technically, the application being run may invoke different behaviour
> depending on the name it was invoked by. Some editors do that, e.g.
> the "joe" editor. But I don't believe Python does anything like this.
>
> http://joe-editor.sourceforge.net/

And quite a few other examples, too - some versions of bash will act
in a more sh-compatible way if invoked as /bin/sh, thus allowing one
to be a link to the other.

Here's how I'm probing Python for this behaviour:

1) Brand new venv

rosuav at sikorsky:~/tmp$ python3 -m venv env

2) With venv active:

(env) rosuav at sikorsky:~/tmp$ python3
Python 3.7.0a0 (default:72e64fc8746b+, Oct 28 2016, 12:35:28)
[GCC 6.2.0 20161010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.executable
'/home/rosuav/tmp/env/bin/python3'
>>> sys.path
['', '/usr/local/lib/python37.zip', '/usr/local/lib/python3.7',
'/usr/local/lib/python3.7/lib-dynload',
'/home/rosuav/tmp/env/lib/python3.7/site-packages']

3) With venv not active:

rosuav at sikorsky:~$ python3
Python 3.7.0a0 (default:72e64fc8746b+, Oct 28 2016, 12:35:28)
[GCC 6.2.0 20161010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.executable
'/usr/local/bin/python3'
>>> sys.path
['', '/usr/local/lib/python37.zip', '/usr/local/lib/python3.7',
'/usr/local/lib/python3.7/lib-dynload',
'/home/rosuav/.local/lib/python3.7/site-packages',
'/usr/local/lib/python3.7/site-packages']

4) Proof that it really is a symlink:

(env) rosuav at sikorsky:~/tmp$ ll env/bin
total 32
-rw-r--r-- 1 rosuav rosuav 2134 Nov  6 05:57 activate
-rw-r--r-- 1 rosuav rosuav 1250 Nov  6 05:57 activate.csh
-rw-r--r-- 1 rosuav rosuav 2414 Nov  6 05:57 activate.fish
-rwxr-xr-x 1 rosuav rosuav  249 Nov  6 05:57 easy_install
-rwxr-xr-x 1 rosuav rosuav  249 Nov  6 05:57 easy_install-3.7
-rwxr-xr-x 1 rosuav rosuav  221 Nov  6 05:57 pip
-rwxr-xr-x 1 rosuav rosuav  221 Nov  6 05:57 pip3
-rwxr-xr-x 1 rosuav rosuav  221 Nov  6 05:57 pip3.7
lrwxrwxrwx 1 rosuav rosuav    7 Nov  6 05:57 python -> python3
lrwxrwxrwx 1 rosuav rosuav   22 Nov  6 05:57 python3 -> /usr/local/bin/python3

5) Moment of truth:

rosuav at sikorsky:~$ tmp/env/bin/python3
Python 3.7.0a0 (default:72e64fc8746b+, Oct 28 2016, 12:35:28)
[GCC 6.2.0 20161010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.executable
'/home/rosuav/tmp/env/bin/python3'
>>> sys.path
['', '/usr/local/lib/python37.zip', '/usr/local/lib/python3.7',
'/usr/local/lib/python3.7/lib-dynload',
'/home/rosuav/tmp/env/lib/python3.7/site-packages']


So it looks like Python actually *does* take notice of the executable
path. This is presumably to allow shebangs to be created the easy way
("#!" + sys.executable) and to always represent the correct Python,
even if you had a venv active.

Now, that said, everything about the previous thread *here* was still
true. People weren't talking about symlinks. But this does mean that
(at least on recent Pythons) running Python from within a venv will
implicitly activate it. (And since the pip* files in that directory
use exactly that shebang, this is also true of running
"tmp/env/bin/pip install spam".)

I'll leave it to someone else to test the older 'virtualenv' module,
as I don't have it installed here.

ChrisA