[Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix

[Roger Binns]

[BTW I apologise for not updating the subject.  My questions are
 in the bigger picture context of Python on Mac, not the need for
 PantherPythonFix]

> You quoted something about link-time linker support for frameworks and 
> then talk about runtime linker support..

On other platforms they are related.  On Windows the contents of a .lib
file at link time determines what .dll is linked to at runtime.  On Linux/
ELF, rpath information (if used) is embedded at link time and affects
runtime.

> If you have Python 2.X and Python 2.Y both installed, as frameworks,

But earlier messages said that only Apple does the frameworks, and
they don't even bother updating the one they did install let alone
install other concurrent versions.

> ... (10.2 compatible) ...

>From this statement and various others it would appear that there
were significant changes in the underlying mechanisms for deploying
Python between 10.2 and 10.3.  I am quite happy to ignore the existence
of 10.2 :-)

> Things aren't done differently..

Frameworks don't exist on the other platforms, nor did changing symbol
resolution, the Mach-O format, just putting all Python stuff in
/usr/lib/python-version or c:\python-version.  There are many
similarities, but it is different.  (If it wasn't I wouldn't be
asking all these questions :-)

> Having extensions that can migrate between Python interpreters 
> installed in different locations (such as inside of an application 
> bundle) is definitely a goal, and was achieved with "-undefined 
> dynamic_lookup" -- but is incompatible with Mac OS X 10.2 and earlier 
> -- so both behaviors have to be supported.

Ok, that all makes sense now.
 
> py2app of course prefers relocatable extensions, but it can solve the 
> issue the hard way by rewriting the extension's Mach-O load commands to 
> relocate it at build time, but there are some edge cases where it won't 
> work (if there isn't enough room in the header to accommodate the new 
> load commands, which has a very, very, very low chance of occurring -- 
> I have never seen it nor heard any reports of it).

I have to do something similar with wxPython on Linux.  It uses rpath
to hard code the location of the wxgtk libraries in the C interface
modules.  That means things just work for users without having to set
their LD_LIBRARY_PATH.  However it is really bad news for distributing
binary apps.  I use a program named chrpath to strip out the rpath's.
The cx-Freeze initialisation code modifies the LD_LIBRARY_PATH to
point to the applications directory first, and so everything works.

> What's hard to understand about "Install this fix if you use Python at 
> all on Mac OS X 10.3"?  If you don't do it, you will probably run 
> across a problem eventually.

The PantherPythonFix is obvious.  The other cases are more interesting,
especially once OS X 10.4 comes out.  At that point I will want to build
on 10.3 using a Python 2.3 interpretter and extensions, and include 
that interpretter and extensions in the app bundle so that 10.4 users
will use the exact same Python as everyone else.

Since you won't make py2app redistribute the system Python, it means
I have to use some other one and then deal with PATH and whatever
else so that the correct one is picked up by default.

And then when we start using Python 2.4, OS X 10.3 will probably still
be the base OS so more interesting version issues will arise.

> This is *not* a Mac-ism.

It is certainly a Mac-ism that the system Python is not redistributable :-)

Roger