Think about how we could change it to python package. #2
Description
It would be more practical to deal with this (big and complex) package if it was pure python as much as possible.
It is currently a ROS package, and that makes testing and messing around less easy than it should be, coming from python.
We could :
- move pyros setup to the .api subpackage
- run tests from tox with system packages enabled on virtualenvs
- get ROS python package directly from repo ( like we do for pyros_msgs )
We should also think about distribution. It makes sense to have a ROS package directly usable for ROS users, but having a pip package available (downloadable as extension) would make it easier for python users as well...