python binary symlinks in Framework build

[Bryan Blackburn]

On Jul 26, 2008, at 9:23 PM, Adam Mercer wrote:

> Hi
>
> In investigating a NumPy build problem I think I have found an issue
> related to the python Framework builds. NumPy, and many other python
> modules, use the python code os.path.basename(sys.executable) to
> return the path to the current running executable for setting which
> interpreter to use. This is $prefix/bin/python2.5, but as this is a
> symlink to the Python binary within the framework directory
> sys.executable is returning
> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
> Resources/Python.app/Contents/MacOS/Python
> which will be shortened to simply Python after the basename call.
>

Actually, ${prefix}/bin/python2.5 isn't a symlink, but that obviously  
doesn't change what sys.executable returns.

Note, however, that this is how Apple's python works too:

$ /usr/bin/python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys
 >>> print sys.executable
/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ 
Python.app/Contents/MacOS/Python

So it seems like the same basename trick would return Python here,  
which works on a case-insensitive FS but I'm guessing would fail on  
sensitive ones?

> As $prefix/bin/Python is a symlink created by python_select this is
> clearly going to cause problems if the default python interpreter is
> changed with python_select.
>

I think python_select is pretty much required at this point, as  
otherwise linking against the framework doesn't work properly without  
python_select'ing python25.

> Can anyone see a solution to this without having to heavily patch the
> NumPy source?
>

Is this about ticket 15865?  Maybe the shebang line can be changed  
with a reinplace?

Bryan


> Cheers
>
> Adam