python binary symlinks in Framework build
Adam Mercer
ram at macports.org
Sat Jul 26 23:37:56 PDT 2008
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?
> 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.
>> 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!
>> 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.
Cheers
Adam
More information about the macports-dev
mailing list