[Distutils] virtual-python.py, sys.prefix, and Mac
Ian Bicking
ianb at colorstudy.com
Wed Sep 19 06:25:06 CEST 2007
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
More information about the Distutils-SIG
mailing list