[Distutils] virtual-python.py, sys.prefix, and Mac

Ronald Oussoren ronaldoussoren at mac.com
Wed Sep 19 07:06:50 CEST 2007


On 19 Sep, 2007, at 6:25, Ian Bicking wrote:

> Ronald Oussoren wrote:
>> On 16 Sep, 2007, at 21:55, Ian Bicking wrote:
>>> Ronald Oussoren wrote:
>>>> On 16 Sep, 2007, at 21:44, Ian Bicking wrote:
>>>>> Ronald Oussoren wrote:
>>>>>> On 15 Sep, 2007, at 18:09, Ian Bicking wrote:
>>>>>>> Hi all.  I'm kind of giving up on workingenv, and have started  
>>>>>>> working
>>>>>>> from virtual-python as a basis instead
>>>>>>> (http://pypi.python.org/pypi/virtualenv/).
>>>>>>>
>>>>>>> So the basic technique here is to copy the executable into
>>>>>>> /ENV/bin/python, and then sys.prefix will be '/ENV'.  The  
>>>>>>> standard
>>>>>>> Python installed on a Mac doesn't seem to do this -- the  
>>>>>>> prefix remains
>>>>>>> '/opt/local/Library/Frameworks/Python.framework/Versions/2.4'
>>>>>>> regardless.  (Custom built Python's on Mac work like normal.)
>>>>>> All framework builds behave as you describe, Modules/getpath.c  
>>>>>> special-cases calculation of sys.prefix for framework builds of  
>>>>>> Python (the prefix is inside the framework regardless of where  
>>>>>> the executable is).
>>>>>
>>>>> Is there any way to effect that calculation?  I.e., in a normal  
>>>>> build that calculation is based on the location of the  
>>>>> executable, so virtualenv moves the executable to effect that.
>>>> Move the framework.
>>>
>>> I don't really know what that means...?  What exactly is the  
>>> framework?
>> The python framework, that is /Library/Frameworks/Python.framework  
>> (or /System/... if you use Apple's build of Python).  getpath.c  
>> uses some API calls to determine the absolute path of the python  
>> framework linked into the current executable and sets sys.prefix to  
>> a directory inside that framework.
>
> Do you have a reference to the getpath.c that it uses?  Windows  
> seems to have something kind of hardcoded, but also a detection  
> scheme, and maybe similarly on Mac there's something I can do to  
> avoid the hardcoded portion.

It is in the python.org source tree: Modules/getpath.c

>
>
>> As background info for anyone that's not used to the mac way: OSX  
>> supports the usual unix organisation of shared libraries but also  
>> has a different method: frameworks. A framework is basicly a  
>> directory containing the shared library, header files and resources  
>> (the last two are optional) and also supports versioning, although  
>> Apple's development tools don't offer full support for that.
>> I should be possible to coax a framework install into support  
>> virtual-python by creating a directory structure for a  
>> python.framework inside the virtual-python environment and using a  
>> simular mechanism as you have now for adding the real stdlib to  
>> sys.path. You will have to modify the copied python executable to  
>> load this mini-framework because the OSX linker adds absolute paths  
>> to shared libraries and frameworks to the executable.
>> The macholib library can be used to do this last task, it is used  
>> by py2app for rewriting the linker commands in shared libraries  
>> that are used in application bundles. I don't have an example for  
>> that handy, but it should be easy enough to extract code from  
>> macho_standalone.
>
> I noticed in p2app it has a file main.c in it, which I think is the  
> Python interpreter code... maybe it recompiles the interpreter?

No, py2app's main.c is something completely different. It is the main  
executable for an application bundle and is very much tuned for that.

Ronald



More information about the Distutils-SIG mailing list