Move messages and services into separate package or repo about capabilities

[wjwwood]

I can do this, but which dependencies are you concerned about?

[wjwwood]

Are we sure this is necessary, is there a compelling case for splitting these up? I would prefer to not make new packages unless there is a good reason. Normally I would agree that splitting up message generation would make sense, but in this case the capabilities package only add roslaunch and rospy to the dependencies. Do you have a case in mind for why this should be done?

[bit-pirate]

I can do this, but which dependencies are you concerned about?

Well, basically I'm trying to keep the dependency of the app manager on the capability server/capabilities low. Preferable would be no dependency at all. I'm already taking care in the implementation, that the app manager runs fine even without a capability server being there. The capabilities package looks very light-weight and as you said, brings in very few dependencies. So, I'm not sure, if this is really an issue.

Looking further, I don't see many nodes ending up depending on the capabilities package (nor a capablities_msgs package). The only nodes doing so would probably be similar in functionality to the app manager. Can you think of other use cases?

[wjwwood]

Well, I am looking at bringing in bondpy too, now, but the app server will have to depend on the capabilities python API anyways, or copy the code where I use bondpy to create a bond. Either way it looks like to implement this reference counting correctly the app server will have to depend on bondpy (and probably already depends on rospy and roslaunch).

So, like I said I am happy to do this if/when you decide we need it.

The only other system that will use the capabilities that I can think of would be:

• rqt_capabilities
• any future capabilities CLI tools
• something like the app server, as you said

[wjwwood]

I'm gonna close this for now, if in the future you think this is required please just comment here and I'll reopen it.