[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
