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?
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 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?
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)?
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.
Thanks,
has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
