On 05/07/2012 04:26 AM, Ronald Oussoren wrote: > On 7 May, 2012, at 11:52, Martin v. Löwis wrote: >>> 3) Symlink the interpreter rather than copying. I include this >>> here for the sake of completeness, but it's already been rejected >>> due to significant problems on older Windows' and OS X. >> >> That sounds the right solution to me. PEP 405 specifies that >> bin/python3 exists, but not that it is the actual Python >> interpreter binary that is normally used. For each target system, a >> solution should be defined that allows in-place updates of Python >> that also update all venvs automatically. >> >> For example, for Windows, it would be sufficient to just have the >> executable in bin/, as the update will only affect pythonXY.dll. >> That executable may be different from the regular python.exe, and >> it might be necessary that it locates its Python installation >> first. For Unix, symlinks sound fine. Not sure what the issue with >> OS X is. > > The bin/python3 executable in a framework is a small stub that > execv's the real interpreter that is stuffed in a Python.app bundle > inside the Python framework. That's done to ensure that GUI code can > work from the command-line, Apple's GUI framework refuse to work when > the executable is not in an application bundle. > > Because of this trick pyvenv won't know which executable the user > actually called and hence cannot find the pyvenv configuration file > (which is next to the stub executable). It occurs to me, belatedly, that this also means that upgrades should be a non-issue with OS X framework builds (presuming the upgraded actual-Python-binary gets placed in the same location, and the previously copied stub will still exec it without trouble), in which case we can symlink on OS X non-framework builds and copy on OS X framework builds and be happy. Carl
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4