[issue42312] sys.prefix is set incorrectly on Mac OS X

Ronald Oussoren added the comment: > 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)? Not that I know. Using the python binary in the virtual envir

[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 interprete

[issue42312] sys.prefix is set incorrectly on Mac OS X

Ronald Oussoren added the comment: I've thought about this some more and haven't changed my opinion: the current behaviour is intentional and won't change. I'm therefore closing this issue. -- resolution: -> wont fix stage: -> resolved status: open -> closed __

[issue42312] sys.prefix is set incorrectly on Mac OS X

Ronald Oussoren 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. -- ___ Python tracker <

[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 ven

[issue42312] sys.prefix is set incorrectly on Mac OS X

Ronald Oussoren added the comment: Note that the same is true for python3 outside of a venv, it does not use argv[0] to locate says.prefix (for framework builds). That’s intentional. -- ___ Python tracker _

[issue42312] sys.prefix is set incorrectly on Mac OS X

Ronald Oussoren added the comment: The difference in behaviour is because the executable does not look at argv[0] to find its location on macOS. Your trick therefore doesn't work. I prefer the current behaviour. What I don't understand is *why* you want to do this. If I read your report cor

[issue42312] sys.prefix is set incorrectly on Mac OS X

Ned Deily added the comment: Sorry, I didn't intend to criticize what you are trying to do, I just not sure I understand it so I could give a more helpful response. It seems to me that an explanation for the difference in behavior you are seeing between your Ubuntu and macOS setups is in exa

[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 w

[issue42312] sys.prefix is set incorrectly on Mac OS X

Ned Deily 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: $ (exec -a test-venv/bin/python3 test-venv/bin/python3 -c 'im

[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);') -- ___

[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 sym