On Sun, Nov 6, 2016 at 3:53 AM, Steve D'Aprano
<steve+pyt...@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@sikorsky:~/tmp$ python3 -m venv env
2) With venv active:
(env) rosuav@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@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@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@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
--
https://mail.python.org/mailman/listinfo/python-list
