The problem to be solved is that in some situations, the wrong Python is run, and it doesn't have PyObjC installed, so the statement
import objc
fails with ImportError
, and the App terminates.In order to fix that, we need to figure out which Python is running and either (i) change which one is run, (ii) remove the "wrong" one, (iii) install PyObjC into the "wrong" one or (iv) provide a path to PyObjC. I fixed my problem before by (ii). I never got (iii) working because I haven't figured out yet how to install
easy_install
when it's not there yet, or alternatively build PyObjC from scratch. What we'll see here leads to the recommendation that you try (i).
We can start our troubleshooting by inserting this code into
main.py
before the import of objc
, as shown:Where does this come from? To begin with, it does not depend on this line in
main.m
:The line can be commented out and everything still runs fine. I think it may be roadkill left over from the old days.
The second thing is that if we look at the Xcode build settings for either the project or the target we see:
Base SDK Mac OS X 10.5
The name or path of the base SDK being used during the build. The product will be built against the headers and libraries located inside the indicated SDK. This path will be prepended to all search paths, and will be passed through the environment to the compiler and linker. Normally, this path is set at the project level via the "Cross-Develop Using Target SDK" popup in the General tab of the project inspector. Additional SDKs can be specified in the ADDITIONAL_SDKS setting. [SDKROOT]
Since the default SDK was set for 10.5, at link time we expect to link against:
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Python.framework
If we double-click on the Python.framework (under Frameworks > Linked Frameworks in the Xcode project) we get a Finder window open to:
/System/Library/Frameworks/Python.framework
If we do get info with the Python.framework selected we get
Name: Python.framework
Path: /System/Library/Frameworks/Python.framework
but all of this says nothing about the version so one might expect it to go with Current, which is actually Python 2.6:
/System/Library/Frameworks/Python.framework/Versions/2.6
I've looked at environment info. Put this in
main.py
:The only thing interesting is:
The
PATH
variable is not the one from my shell. But there isn't any Python in /Developer/usr/bin
and both Python and python in /usr/bin
give 2.6. So that's not where it comes from. $PYTHONPATH just points to the App.Let's try to find out more using this trick:
We're clearly loading the 2.5 framework. And this behavior can be changed by changing the SDK in Xcode. However, I can't show you anything more right now because I no longer have a failing example! (here)
I don't see anything in any of the settings for the Project, Target or Executable that would explain which Python is actually launched when the App runs. (As you'll see in a minute, there are two choices even for the Python.framework, for example in Version 2.5).
There is some weirdness about the system framework. On three different machines running OS X 10.6.5: Python at top-level in the 2.5 framework seems to be a dynamically linked library.
But it actually runs
/usr/bin/Python
which is 2.6!:The whole second half of the post, and the part just above, is a hideous mistake. See here for details.
The stupid, it burns.link
Or as my boss likes to tell me, "some days you're the dog, and some days you're the hydrant"---he's amused, me not so much.