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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
