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). Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
