python binary symlinks in Framework build

Bryan Blackburn 0x62_0x6c_0x62 at pobox.com
Sun Jul 27 01:54:14 PDT 2008


On Jul 27, 2008, at 12:37 AM, Adam Mercer wrote:

> On Sat, Jul 26, 2008 at 10:48 PM, Bryan Blackburn
> <0x62_0x6c_0x62 at pobox.com> wrote:
>
>> Actually, ${prefix}/bin/python2.5 isn't a symlink, but that obviously
>> doesn't change what sys.executable returns.
>
> Thats a good point, so shy does sys.executable return the Framework  
> binary?
>

Good question, calculate_path() does most of the work, but there's  
quite a bit to it:

<http://svn.python.org/view/python/tags/r252/Modules/getpath.c?rev=60915&view=auto 
 >

>> 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?
>
> True, but just because that is the way the Apple does it does not mean
> it is the correct way.
>

I mention this because anyone installing, say, numpy with the Apple- 
provided version must be doing something about this as well.  Not to  
mention we can't exactly look to other OS's to see how they do  
framework installs...

>>> 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.
>
> In that case we need to think about how the current ports system
> handles python ports, as if it is required that people run
> python_select before the different python ports will work then that
> will only lead to problems!
>

Note the post activate section of python25 already basically suggests  
this:

post-activate {
     ui_msg "\nTo fully complete your installation and make python  
$branch the default, please run
\n\tsudo port install python_select \
\n\tsudo python_select $name\n"
}

>>> 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?
>
> It is, and that would indeed solve the problem but I would prefer this
> problem be solved in python25 and not in the individual python ports.
>

Of course replacing the shebang line would truly tie it to the proper  
python if you used ${prefix}/bin/python2.5, which protects against  
both the issue with env if ${prefix}/bin is after /usr/bin in PATH, as  
well as when multiple python versions are installed with MacPorts.  If  
someone has python25 and python26, but does a python_select on 2.6,  
all py25- ports using env will now most likely break...

Probably the best place for this is perhaps an addition to the python  
group code to specify scripts to be installed, and have that rewrite  
shebang lines as appropriate maybe?

Bryan


> Cheers
>
> Adam


More information about the macports-dev mailing list