[Pythonmac-SIG] portability problem with py2app-built app

[Bob Ippolito]

On Jan 23, 2005, at 10:32, has wrote:

> Bob wrote:
>
>>> Having a problem with a semi-standalone app built using py2app 
>>> 0.1.7. Building it OMM (OS10.2.8, MacPython 2.3.3) and the app works 
>>> fine here, but on the user's machine (OS10.3, standard 
>>> Apple-installed MacPython) it shows a dialog saying that it requires 
>>> Python 2.3. What's wrong?
>>>
>> Nothing.  The semi-standalone option depends on an equivalent Python 
>> installation and it didn't find one. An equivalent Python 
>> installation means that there is either one in the bundle, or on the 
>> filesystem in an identical location.
>
> Ahh, right. This wasn't obvious.
>
>
>> When using --semi-standalone, your Python extensions can't have their 
>> Mach-O headers rewritten. If they are linked on a version of Python 
>> or platform that doesn't use -undefined dynamic_lookup,
>
> You mean installations like (e.g.) Apple's MacPython on 10.3? Sorry my 
> C/ObjC is extremely limited - probably best if it's explained in dummy 
> talk. Is there a definitive document I can go read that describes the 
> scope, scale and implications of this problem?

I've posted summaries of the multiple python problem to this list 
before, you'll have to search the archives.. I don't have a link handy, 
and it's not really documented elsewhere.

>> You can override the contents of PyRuntimeLocations with the plist 
>> option, but the recommended solution to building a Python application 
>> that runs on multiple versions of OS X is to use a standalone bundle 
>> built on[1] the earliest supported version of Mac OS X.
>
> Only problem with that is it bumps each app's size by about 7MB, which 
> is a bit of a hog for any user on dialup... especially if I'm shifting 
> serveral 'small' apps at a time.

In my 10.2 compatible application, zipped with -r9 (minus non-Python 
resources), it is less than 2 megs.  2 megs is a lot less than 7 :)

>> In the future, py2app may audit your application to determine if it 
>> is safe to use "any" version of Python (no extensions, or extensions 
>> with only -undefined dynamic_lookup).. however, that still won't 
>> support your use case.
>
> My immediate problem is making ASTS portable, but I've got other apps 
> in development that are going to have the same problem. And I can't 
> afford a copy of 10.3 to do a parallel build on, so building 
> cross-platform on 10.2 is currently my only option. What if I exclude 
> appscript from the app (it can be provided as a separate one-off 
> installation via a third-party binary installer) and munge its 
> Info.plist to pick up Apple's MacPython?

That creates the same problem all in a different context.  If you can't 
build 10.3 extensions, then you can't build 10.3 extensions, and you 
will ALWAYS have the multiple python problem UNLESS you are using 
standalone builds.

>> In theory, it could use macholib to rewrite the headers at runtime 
>> into a temp dir if it determines that this is necessary, but I'm not 
>> going to implement that.
>
> Would this solve the problem (and at what cost)?

Quite a bit of development for very little return.  It's only relevant 
to OS X 10.2 compatible --semi-standalone builds, which I don't care 
about at all.  When I do 10.2 compatible applications, I need to make 
them standalone because they are for consumers.  I'd rather buy you a 
copy of 10.3 than write this code, but I'm not going to do either :)

> Any other options open to me? I can solve the ASTS problem by having a 
> 10.3 build included in the 10.3 binary installer, but it does put a 
> bit of a damper on me other ambitions until I can raise the cost of an 
> upgrade or two.

Not really.

-bob