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 : [EMAIL PROTECTED] : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
