OK, I think the mystery is largely solved. Inside the chirp.app package, I find the following (edited for brevity):

dan[Contents]$ pwd /Applications/_Dans_apps/chirp-daily-20140407.app/Contents dan[Contents]$ ll ... lrwxr-xr-x 1 dan staff 103 Apr 9 13:40 CHIRP -> /opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

So there's a symbolic link to the "correct" Python inside the package, created about the time I first ran it. (In addition to a fresh hg clone, I thought I'd update my operating bits as well). So where did that link come from?

===================== dan[Contents]$ cat Macos/chirp #!/bin/bash

LOCATION=$(dirname "${BASH_SOURCE}")

PYTHON=/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

if [ -x $PYTHON ]; then ln -s $PYTHON "${LOCATION}/../CHIRP" PYTHON=${LOCATION}/../CHIRP export PYTHONPATH="/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/" else PYTHON=/opt/kk7ds/bin/python2.7 fi

exec "$PYTHON" "${LOCATION}/../Resources/chirp/chirpw" =======================

Looks like somebody decided that the wrong Python was getting used too often, and taught chirp to find the right one and use it.

But no such magic is in place for run_tests. I know how to deal with it.

Thanks for the clues.

-dan

On Apr 9, 2014, at 3:40 PM, Tom Hayward - esarfl@gmail.com wrote:

...

... ImportError: No module named serial

run_tests is trying to use /usr/bin/python instead of /opt/kk7ds/bin/python. /opt/kk7ds/bin/python is the version that includes python-serial. There are a few ways to resolve this. I'll defer that to someone else (you can probably figure it out).

...

I'm on a Mac running OS X 10.9.2 Chirp runs ok, it says I'm using (Python 2.7.2).

I'm curious how you are running Chirp ok without python-serial. I have to call Chirp like this on OS X: /opt/kk7ds/bin/python ./chirpw