[issue46890] venv does not create "python" link in python 3.11

Steve Dower added the comment: > This could be problematic, adding a suitably named file outside of $PREFIX > breaks the python installation. Might be worth changing it then. I double/triple checked whether searching up for the zip file was the old behaviour, and it sure seemed to be (it

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: WITH_NEXT_FRAMEWORK is a compile time option, I've added it to globals in values like PREFIX are added. That way the python code can behave differently for framework builds (which appears to be needed). There are two big problems with my patches: -

[issue46890] venv does not create "python" link in python 3.11

Steve Dower added the comment: > I have a patch that seems to do the right thing. It required adding > WITH_NEXT_FRAMEWORK to the globals when evaluating getpath.py to detect this > scenario. I haven't had a chance to go through all your changes, and I'm only very vaguely familiar with

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: I've attached a new patch file with some more tweaks, including the additional test case from msg414665. I've pretty sure that the changes to getpath.py are slightly worse in the new version, but aren't fully correct in the initial version as well (see my

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: I'm now in the fun position where the code works, but the test test_getpath.py fails. The test case below tries to test a venv in a framework build, but somehow fails to calculate prefix and exec_prefix correctly. The calculation does work when using a

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: This is also dodgy: test_framework_macos (test.test_getpath.MockGetPathTests) ... Read link from /Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python Check if

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: I have a patch that seems to do the right thing. It required adding WITH_NEXT_FRAMEWORK to the globals when evaluating getpath.py to detect this scenario. There probably should be more tests, in particular a test for a virtual environment using a

[issue46890] venv does not create "python" link in python 3.11

Steve Dower added the comment: > I've pasted the diff below because I'm not yet convinced that it is correct > (in particular the value for "argv0".) argv0 is literally what C sees in argv[0], which in the framework case I believe is calculated by a launcher? The getpath.py change is

[issue46890] venv does not create "python" link in python 3.11

Pablo Galindo Salgado added the comment: Ok, marking is at "deferred blocker" -- priority: release blocker -> deferred blocker ___ Python tracker ___

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: > This is marked as a release blocker so I am holding the alpha release on > this. Is there anything we can do to unblock this issue? I marked the issue as a release blocker because it must not end up in a beta release, its probably not worth it to hold up

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: Again without diving deep I've constructed a test case that is probably relevant. I've pasted the diff below because I'm not yet convinced that it is correct (in particular the value for "argv0". This would also require a second test case that does

[issue46890] venv does not create "python" link in python 3.11

Pablo Galindo Salgado added the comment: This is marked as a release blocker so I am holding the alpha release on this. Is there anything we can do to unblock this issue? -- nosy: +pablogsal ___ Python tracker

[issue46890] venv does not create "python" link in python 3.11

Ned Deily added the comment: To reiterate, the example I gave had nothing to do with using a venv. The value of sys._base_executable is now always wrong whether or not using a venv. The consequences are more obvious when using a venv. -- ___

[issue46890] venv does not create "python" link in python 3.11

Steve Dower added the comment: > If there's a way to add a test for this case as well, that would be > handy. Way too little documentation here. There's definitely a way to add a test now, because test_getpath uses completely fake initial conditions to verify that getpath.py does its thing.

[issue46890] venv does not create "python" link in python 3.11

Steve Dower added the comment: > Is sys._base_executable updated after running getpath.py? It shouldn't be, but site.py might do it. More likely it's in how getpath.py is handling the environment variable overrides. It should be pretty easy to track down and change - the old "logic" was

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: The change to _base_executable is the real problem. Venv creates the correct directory structure if I add a sitecustomize.py to the python path that sets _base_executable to the correct value. # sitecustomize import sys sys._base_executable =

[issue46890] venv does not create "python" link in python 3.11

Ned Deily added the comment: As Ronald notes, the issue isn't in venv, it's that the value of sys._base_executable has changed between 3.10 and 3.11 for macOS builds. $ /usr/local/bin/python3.10 Python 3.10.2 (v3.10.2:a58ebcc701, Jan 13 2022, 14:50:16) [Clang 13.0.0 (clang-1300.0.29.30)] on

[issue46890] venv does not create "python" link in python 3.11

Steve Dower added the comment: The _base_executable change might be, though it should still be preferring the environment variables here, but I don't think I touched anything that would affect which symlinks are created by venv. -- nosy: +vinay.sajip

[issue46890] venv does not create "python" link in python 3.11

Eric Snow added the comment: This may be related to the getpath.py work Steve did. -- nosy: +eric.snow, steve.dower ___ Python tracker ___

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: The root cause likely is the calculation of sys._base_executable. In 3.10 this is {sys.prefix}/bin/python3.10, while in 3.11 this is {sys.prefix}/Resources/Python.app/Contents/MacOS/Python. The venv library uses the incorrect value and therefore creates an

[issue46890] venv does not create "python" link in python 3.11

Ronald Oussoren added the comment: This is be related to how the virtual environment is populated. In 3.10 the "python3.10" name in the environment is a symlink to sys.executable. In 3.10 "Python" (not the capital) is a symlink to the binary in Python.app and "python3.11" is a symlink to

[issue46890] venv does not create "python" link in python 3.11

Change by Zachary Ware : -- title: vent does not create "python" link in python 3.11 -> venv does not create "python" link in python 3.11 ___ Python tracker ___