[Python-Dev] PEP 405 (pyvenv) and system Python upgrades

Carl Meyer carl at oddbird.net
Mon May 7 17:25:41 CEST 2012


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


More information about the Python-Dev mailing list