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

[Ian Bicking]

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.

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


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers