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
_______________________________________________
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
