search

git-afsantos / haros

H(igh) A(ssurance) ROS - Static analysis of ROS application code.
MIT License
191 stars 37 forks source link

'haros init' fails with "KeyError: ROS_WORKSPACE" #41

Closed gavanderhoorn closed 5 years ago

gavanderhoorn commented 5 years ago

After resolving #40 (so with the base /opt/ros/kinetic/setup.bash sourced and pyflwor installed), running haros init results in:

[HAROS] It seems this is a first run.
Traceback (most recent call last):
  File "/home/user/venv_haros/bin/haros", line 10, in <module>
    sys.exit(main())
  File "/home/user/venv_haros/local/lib/python2.7/site-packages/haros/haros.py", line 725, in main
    if launcher.launch(argv = argv):
  File "/home/user/venv_haros/local/lib/python2.7/site-packages/haros/haros.py", line 142, in launch
    self.command_init(args, HarosSettings())
  File "/home/user/venv_haros/local/lib/python2.7/site-packages/haros/data.py", line 454, in __init__
    self.workspace = workspace or self.find_workspace()
  File "/home/user/venv_haros/local/lib/python2.7/site-packages/haros/data.py", line 504, in find_workspace
    raise KeyError("ROS_WORKSPACE")
KeyError: 'ROS_WORKSPACE'

Only after having sourced a setup.bash of a ROS workspace does init continue and clones the plugins repository.

git-afsantos commented 5 years ago

Indeed, the current version more or less assumes that you already have a working ROS development environment. Perhaps I should try to relax that behaviour a bit, as I am getting more use cases that do not follow that pattern.

gavanderhoorn commented 5 years ago

Indeed, the current version more or less assumes that you already have a working ROS development environment.

So not having a local workspace (but having sourced /opt/ros/kinetic/setup.bash) doesn't fulfil that requirement?

git-afsantos commented 5 years ago

The original idea was that HAROS would be used to analyse the source of your own projects, and so we could make the assumption that you would have a workspace, and that it would be sourced. In most setups, I do not think /opt/ros would have any source code (C++ at least, besides headers), and that is why I dismissed that case.

Do you think this is too strict? I could look into what I would have to change to relax this requirement.

gavanderhoorn commented 5 years ago

The original idea was that HAROS would be used to analyse the source of your own projects, and so we could make the assumption that you would have a workspace, and that it would be sourced. In most setups, I do not think /opt/ros would have any source code (C++ at least, besides headers), and that is why I dismissed that case.

Makes sense.

Do you think this is too strict? I could look into what I would have to change to relax this requirement.

It's not necessarily too strict, I just wanted to make sure I understood things correctly.

I don't think it makes much sense to be able to scan /opt/ros as it only includes binaries.

Although it does contain Python for all the Python nodes. Those could still be parsed -- if HAROS would support Python.

gavanderhoorn commented 5 years ago

I would recommend printing a more user friendly error message though than a KeyError ;)

git-afsantos commented 5 years ago

Although it does contain Python for all the Python nodes. Those could still be parsed -- if HAROS would support Python.

Andrzej has a student working on Python support, as far as I know.

Parsing those nodes should not be a problem, I think. HAROS more or less replicates rospack find <pkg>, and then goes from wherever the package is.

I would recommend printing a more user friendly error message though than a KeyError ;)

There are quite a lot of error messages that need improvement, indeed! I should make a list of known cases and open an issue for that.

git-afsantos commented 5 years ago

@gavanderhoorn I have remedied the KeyError issue with a nicer message. Further work on error handling is tracked in #49.