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...
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 :
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...