[issue42312] sys.prefix is set incorrectly on Mac OS X
Michael Ferguson added the comment: > The way sys.prefix is calculated on macOS ensures that the correct sys.prefix > is calculated even if you copy the binary to a different location. That's > functionality I don't want to drop. I agree with you that it's important for the Python interpreter to find the libraries it is installed with even if the framework launcher is copied to a different location. However I think it's possible to support finding the installation while fixing the issue I am bringing up. Finding the installation amounts to getting the correct `sys.base_prefix` (no matter where the launcher is copied). It seems to me that if the launcher is copied to a different directory, `sys.prefix` should change in some cases. That already happens when making a `venv` with copies instead of links. Could the framework launcher consider `argv[0]` without causing problems in this use case? I think this is a bug and not a feature tradeoff because a platform-specific wrapper should be as transparent as possible and as a result should keep the `argv[0]` behavior that occurs without the wrapper. In any case, do you think that there is a way to get the behavior I am looking for (basically, invoke a Python interpreter that has sys.prefix set to the venv but without a symbolic link)? -- ___ Python tracker <https://bugs.python.org/issue42312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42312] sys.prefix is set incorrectly on Mac OS X
Michael Ferguson added the comment: > For example, when I run the test exec on my macOS system, it is clear that > the python3 being invoked is not the venv one but a different python3 > altogether that shows up earlier on PATH. In the test case I am interested in, PATH is not set to the venv at all. You're supposed to be able to run a script in a venv without activating. In my case, I am trying to write a wrapper script that behaves similarly to the symbolic link in test-venv/bin/python3 but that works if the path to the python3 interpreter changes in the future. (For example, one might install and then uninstall pyenv). -- ___ Python tracker <https://bugs.python.org/issue42312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42312] sys.prefix is set incorrectly on Mac OS X
Michael Ferguson added the comment: > I'm not sure I understand exactly what you are trying to accomplish but one > potential issue strikes me: you may need to ensure you are execing the right > python binary by including a more complete path: That does not help with the original problem I was trying to solve, because I was trying to create a wrapper script that used whichever `python3` is available according to the `PATH` variable (other than potentially the one for this venv). Whether or not you think that is a reasonable thing to do, the examples I showed have a difference in behavior between Mac OS X and linux that is probably undesirable. -- ___ Python tracker <https://bugs.python.org/issue42312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42312] sys.prefix is set incorrectly on Mac OS X
Michael Ferguson added the comment: In the above I meant to include the `bin` path in the examples, but it does not matter for the behavior (exec -a test-venv/bin/python3 python3 -c 'import sys; print(sys.executable); print (sys.prefix);') -- ___ Python tracker <https://bugs.python.org/issue42312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42312] sys.prefix is set incorrectly on Mac OS X
New submission from Michael Ferguson : I have been trying to create a wrapper script for `python3` in a venv that behaves similarly to a symbolic link. I am able to use `exec -a` in bash to run `python3` with `argv[0]` set to the wrapper script. This allows it to function similarly to the symbolic link in a venv. However, this approach does not work on Mac OS X with a homebrew installation. I think this is a bug. Here are the simple steps to reproduce (assuming bash shell): ``` cd /tmp python3 -m venv test-venv (exec -a test-venv/python3 python3 -c 'import sys; print(sys.executable); print (sys.prefix);') ``` ### Good output (Ubuntu 20.04) /tmp/test-venv/python-wrapper /tmp ### Bad output (Homebrew on Mac OS X) /usr/local/opt/python@3.9/bin/python3.9 /usr/local/Cellar/python@3.9/3.9.0_1/Frameworks/Python.framework/Versions/3.9 Here are some things that might be related: * the Mac OS X framework launcher and how it uses `realpath` (and issue22490) * `site.py` code in `def venv` and the conditional on `__PYVENV_LAUNCHER__`. The `if` branch is not being run in this configuration. * setting the environment variable `PYTHONEXECUTABLE` (e.g. `export PYTHONEXECUTABLE=test-venv/python3` before the other commands) causes the `if` branch in the conditional on `__PYVENV_LAUNCHER__` in `site.py` `def venv` to be run. This allows `sys.executable` to be set as expected but `sys.prefix` is still wrong. If you are interested in something closer to the use case, the below explains how to get a more user-facing reproducer: $ python3 -m venv test-venv -- put this into test-venv/python-wrapper -- #!/usr/bin/env bash # remove path component to prevent infinite loop export PATH=${PATH//test-venv/missing} # Now run the real python3 interpreter but tell it that it # is being launched at the current path, so it can # correctly find dependencies in the venv exec -a "$0" python3 "$@" $ chmod a+x test-venv/python-wrapper $ ./test-venv/python-wrapper -c 'import sys; print(sys.executable); print (sys.prefix);' (and with this script the problematic behavior is exactly the same as the exec commands above) -- components: macOS messages: 380677 nosy: mppf, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: sys.prefix is set incorrectly on Mac OS X type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com