Running simulator on OS X gives the following error (shown in a QT modal dialog window):
Traceback (most recent call last): File "./scripts/simulator.py", line 576, in __process_queue self.__class__.__dict__[name](self,*args) File "./scripts/simulator.py", line 94, in read_config self.load_world(world) File "./scripts/simulator.py", line 102, in load_world self.__construct_world() File "./scripts/simulator.py", line 142, in __construct_world sup_class = helpers.load_by_name(thing.supervisor.type,'supervisors') File "./scripts/helpers.py", line 111, in load_by_name module = __import__(path, globals(), locals(), [filename]).__dict__[filename] File "pysimiam-coursera-week7/supervisors/week7.py", line 9, in <module> from supervisors.quickbot import QuickBotSupervisor File "pysimiam-coursera-week7/supervisors/quickbot.py", line 9, in <module> from supervisor import Supervisor ImportError: cannot import name Supervisor $ python Python 2.7.9 (default, Dec 30 2014, 18:33:32) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Hm, that's weird. Just to make sure the environment is sane:
Hi Tim,
Thanks for the prompt reply. See my comments inline.
Yes. But, is there more than one way to run the application?
or
Quick search of the error messages gets me to this SO thread, could it be related?
http://stackoverflow.com/questions/9252543/importerror-cannot-import-name-x
This will be interesting.
The error that you are seeing means that although Python has found a file "supervisor.py", there is nothing named "Supervisor" in it. Since we have established that there is actually a class named Supervisor in scripts/supervisor.py, this seems to indicate that there is another file supervisor.py in path that gets found before the correct one.
qtsimiam_week7.py adds the "scripts" folder to the path, so it is important that it is run somehow (I don't think there are many ways to run it - command-line or Finder). But this is being done already.
Can you check if there are any other supervisor.py files in the pysimiam folder and subfolders? For example in "supervisors/"? If there are, please rename them to something else. If there is only scripts/supervisors.py, then we have to check the path. Please add
in the beginning of load_by_name method in scripts/helpers.py and check what is printed in the terminal. Mine looks like this:
Well, I did not add or remove any files from the original package.
Here is the output after adding sys.path as you suggested:
I must say that this is only OS X issue. AFAIR, on Linux the simulator works fine, however right now I don't have it at hand to run and compare.
The problem is that not only is this a Mac OS X-specific issue, it also seems to depend on the particular setup, because I cannot reproduce it on my Mac (I am using python from Anaconda). I will think about it some more.
Please try the attached archive and tell me if it works.
Yes, I'm glad to say it's working now.
Some namespace collisions caused the issue? Any idea why it didn't work only in my env? )
In any case, thanks for all your help.
I'm still not sure why it didn't work on your machine - as I've said, python tried to import something different from what it should have. As you say, some namespace collision. All I did was to switch to fully qualified imports for the scripts folder, without playing with the sys.path, and it worked.
Actually, I know what else we could have tried. The error message was
So you can try to replace
with
This should tell us where the imported file is.
Finally figured what was causing this.
I have a supervisor package installed in my system (installed via
pip install supervisor
).It installs a system module with same name, which was imported instead of local.
Yeah, unique namespaces are great way avoid such issues.
Thanks for you help!
Thank you for reporting the bug and finding the cause. Apparently I didn't quite understand how the import mechanism works - sys.path seems to be the last place where it looks.
If you don't mind me asking, how come you have started with week7? Or did you do finish all other weeks earlier?
Yeah, I'm glad it's solved now. I got my lesson from this.
As probably most of the users of this simulator I started with matlab version, completed about 3-4 week and then realized that matlab is a bit difficult to work with, and python would be more dev friendly (ironically, it hadn't been until now). Now I have a chance to proceed from where I left off. And it looks like it was well worth the effort, the GUI looks great, and seems like debugger just works without matlab 'hacks'.
Then good luck with week 7. Please let me know if you encounter any other problems.