Re: [chirp_devel] run_tests: No module named serial
Tom,
I edited the shebang line to insert the path to the "correct" python so I could run the tests. But I think that might be a mistake to do for all users.
I'm not sure, but run_test is not a Mac-only file, is it? I assume that most linux users have the "correct" Python in /usr/bin/python, or else nobody is running tests? Nobody develops chirp on a Mac? Or those that do overwrite the Apple-supplied python?
Even on a Mac, I note that the shell script in the app looked in two places for it. Can't do that on the shebang line, so it would have to be wrapped in a script - but which shell works on all platforms?
And I have no idea what Windows would do here. Plus, I can't test it other than on a Mac. Sounds like lots of trouble created for other developers.
I don't mind doing the work, it's going to be a pain editing run_tests every time, and then restoring it so hg doesn't try to add it to a patch. I could probably add a mac_run_tests wrapper, essentially duplicating what the script in the app does.
You're busy. This isn't urgent. Give me some direction so I'm not going to break stuff for others, and I'll do it.
-dan
On Apr 9, 2014, at 4:48 PM, Tom Hayward - esarfl@gmail.com wrote:
Sorry I don't have the time to focus on this right now, but here's another hint: http://stackoverflow.com/questions/2429511/why-do-people-write-usr-bin-env-p...
Notice that this is *not* how Dan calls Python from run_tests. You might fix it and submit it as your first bug fix :-)
Tom KD7LXL
Yeah, I think the "right way" (i.e., cross platform) would be to use a combination of manipulating PATH and various python env vars (see ENVIRONMENT VARIABLES in man python) such as PYTHONHOME, et al for a given development environment. Normally you would have a "helper/launcher" script or something that sets/exports these into a bash/terminal/shell/commandline/etc session.
I have just a simple "runchirp" script that gets me going on mac:
#!/bin/bash CHIRP_DEBUG=True /opt/kk7ds/bin/python chirp.hg/chirpw
________________________________ From: "chirp.cordless@xoxy.net" chirp.cordless@xoxy.net To: chirp_devel@intrepid.danplanet.com Sent: Wednesday, April 9, 2014 11:01 PM Subject: Re: [chirp_devel] run_tests: No module named serial
Tom,
I edited the shebang line to insert the path to the "correct" python so I could run the tests. But I think that might be a mistake to do for all users.
I'm not sure, but run_test is not a Mac-only file, is it? I assume that most linux users have the "correct" Python in /usr/bin/python, or else nobody is running tests? Nobody develops chirp on a Mac? Or those that do overwrite the Apple-supplied python?
Even on a Mac, I note that the shell script in the app looked in two places for it. Can't do that on the shebang line, so it would have to be wrapped in a script - but which shell works on all platforms?
And I have no idea what Windows would do here. Plus, I can't test it other than on a Mac. Sounds like lots of trouble created for other developers.
I don't mind doing the work, it's going to be a pain editing run_tests every time, and then restoring it so hg doesn't try to add it to a patch. I could probably add a mac_run_tests wrapper, essentially duplicating what the script in the app does.
You're busy. This isn't urgent. Give me some direction so I'm not going to break stuff for others, and I'll do it.
-dan
On Apr 9, 2014, at 4:48 PM, Tom Hayward - esarfl@gmail.com wrote:
Sorry I don't have the time to focus on this right now, but here's another hint: http://stackoverflow.com/questions/2429511/why-do-people-write-usr-bin-env-p...
Notice that this is *not* how Dan calls Python from run_tests. You might fix it and submit it as your first bug fix :-)
Tom KD7LXL
_______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
On further review, I have an alternative proposal. Given the hints from Tom and Jens that python ignores the shebang line (!!), I just created an alias for the kk7ds python, and run it as % kk7python run_tests Works fine, so I don't need to edit the script.
But in the cause of incremental positive improvement, here's a suggestion for a patch to the file that might help the next newbie resolve this without help:
========== diff -r 1cc897a1d161 tests/run_tests --- a/tests/run_tests Wed Apr 09 20:30:12 2014 -0700 +++ b/tests/run_tests Thu Apr 10 10:04:59 2014 -0700 @@ -17,7 +17,12 @@
import traceback, sys, os, shutil, glob, tempfile, time from optparse import OptionParser -from serial import Serial +try: + from serial import Serial +except ImportError,e: + print "\nNo module named serial found.\n" \ + "This script must be run with the kk7ds Python distribution" + sys.exit(1)
# Assume we're running in the tests/ directory of the archive sys.path.insert(0, "../") ===========
That behaves as intended, both cases. I'm a bit green on the try/except paradigm, so I thought I'd post it for review.
Shall I make this patch?
-dan
... I don't mind doing the work, it's going to be a pain editing run_tests every time, and then restoring it so hg doesn't try to add it to a patch. I could probably add a mac_run_tests wrapper, essentially duplicating what the script in the app does.
On Apr 9, 2014, at 4:48 PM, Tom Hayward - esarfl@gmail.com wrote:
Sorry I don't have the time to focus on this right now, but here's another hint: http://stackoverflow.com/questions/2429511/why-do-people-write-usr-bin-env-p...
Notice that this is *not* how Dan calls Python from run_tests. You might fix it and submit it as your first bug fix :-)
Tom KD7LXL
But in the cause of incremental positive improvement, here's a suggestion for a patch to the file that might help the next newbie resolve this without help:
Personally, I think that leaving the import bare and letting it fail is the right way. If you look at most python apps, they do not try to gracefully import things that are core dependencies and print special messages. We do that for things that are optional that we can work around if they're not present, but pyserial is not optional and thus I don't think we should be defensive about such things.
If others think this is really important, then that's fine, but IMHO, it's just not worth it. It's documented on the developers page as a requirement and was just a little less obvious because you're running out of the MacOS package.
--Dan
participants (3)
-
chirp.cordless＠xoxy.net -
Dan Smith -
Jens J.