FWIW, the same thing seems to happen for me on Tiger using the original virtual-python.py against the Apple-compiled Python that ships with it: [chrism@kingfish macsandbox]$ /usr/bin/python ~/bin/virtual-python.py --prefix=.Creating ./lib/python2.3 Creating ./lib/python2.3/site-packages Creating ./include/python2.3 Creating ./bin Copying /usr/bin/python to ./bin You're now ready to download ez_setup.py, and run ./bin/python ez_setup.py [chrism@kingfish macsandbox]$ ls bin include lib [chrism@kingfish macsandbox]$ bin/python Python 2.3.5 (#1, Jan 13 2006, 20:13:11) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "help", "copyright", "credits" or "license" for more information.

...

...

import sys sys.prefix '/System/Library/Frameworks/Python.framework/Versions/2.3'

- C On Sep 15, 2007, at 12:30 PM, Philipp von Weitershausen 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.)

Since I'm the one who's experiencing this, here's some more info:

* Both the Python 2.4 from MacPorts as well as the binary MacPython package fail to create a virtualenv because sys.prefix of the copied executable still points to the old location.

* Self-compiled Python 2.4 and 2.5 doesn't have this problem, nor does the Python 2.5 from MacPorts or the MacPython 2.5 binary (!!!)

So this seems to be constrained to Python 2.4 from MacPorts and MacPython.

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

Andreas Jung wrote:

--On 15. September 2007 11:09:44 -0500 Ian Bicking <ianb@colorstudy.com> 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/).

I tried virtualenv - however the python in the new environment contains all eggs in sys.path that are installed for the original Python interpreter.

Bug or feature?

You have to use --no-site-packages to avoid that. -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

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.

...

Does anyone know a way to get the normal effect on this Mac Python?

You could copy the framework into the virtual python environment and rewrite linker commands in the python command-line executable to use that version of the framework.

That sounds like the similar situation to the standard library on other posix systems, which I've avoided copying. To do that, I put a text file in that points to the original stdlib location, and in site.py I add that in (I only copy the portions of the stdlib that are needed when site.py is loaded -- os, re, etc). So the same thing should be possible with the framework, and that's not too much of a problem. I don't have any idea how to figure out the linker commands to change the Python command-line executable...? I don't even have the vocabulary to begin figuring that out, I'm afraid. Can you give an example? -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

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? -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

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@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

Ronald Oussoren wrote:

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

...

Ronald Oussoren 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

On 16 Sep, 2007, at 21:55, Ian Bicking wrote: 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

That's the file used in the Framework build of Python? I only see some small references to __APPLE__, none of which seem related to Frameworks. Also, if you build Python from source it works fine -- it's only the python that Apple ships that has the problem. They must use some patched version of this file that they use...? -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

Ronald Oussoren wrote:

On Wednesday, September 19, 2007, at 07:26AM, "Ian Bicking" <ianb@colorstudy.com> wrote:

...

...

It is in the python.org source tree: Modules/getpath.c That's the file used in the Framework build of Python? I only see some small references to __APPLE__, none of which seem related to Frameworks. Also, if you build Python from source it works fine -- it's only the python that Apple ships that has the problem. They must use some patched version of this file that they use...?

Start reading at line 694 in Modules/getpath.c, that's in the head of the release25-maint branch.

It's only 695 lines long...? At line 458 it seems like it is looking for lib/python2.5/os.py, in some Framework-specific code. It will look relative to the binary, but only after looking in the Framework first. Simply breaking the Framework lookup somehow would do it. Here's the code to find the Framework locations: pythonModule = NSModuleForSymbol(NSLookupAndBindSymbol("_Py_Initialize")); /* Use dylib functions to find out where the framework was loaded from */ buf = (char *)NSLibraryNameForModule(pythonModule); I'm not sure how to do anything to that though. -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers