Revision history [back]

I interpret "don't do that unless you're desperate in defining what's ought to be loosely coupled dependency"

I could see a use for an application package -- which would basically be a metapackage -- which essentially defines the set of packages (as exec_depends) which together contain the functionality required for a specific application to function correctly.

So plus_one_app1 could be a metapackage stating exec_depends on plus_one_secret_pkg1 and plus_one_generic_ui and moveit. If plus_one_app1 is then deployed, the requirements at the level you consider in your question would be satisfied (as in: the packages present in the workspace / on the machine are capable of satisfying the runtime requirements of all parts of the application, as deployed).

That's not completely the same as modelling "this node requires sensor_msgs/Image input at 10 Hz", which seems to be more like what you're after.

But by virtue of those specific packages being deployed together, ..

I interpret "don't do that unless you're desperate in defining what's ought to be loosely coupled dependency"

I could see a use for an application package -- which would basically be a metapackage -- which essentially defines the set of packages (as exec_depends) which together contain the functionality required for a specific application to function correctly.

So plus_one_app1 could be a metapackage stating exec_depends on plus_one_secret_pkg1 and plus_one_generic_ui and moveit. If plus_one_app1 is then deployed, the requirements at the level you consider in your question would be satisfied (as in: the packages present in the workspace / on the machine are capable of satisfying the runtime requirements of all parts of the application, as deployed).

That's not completely the same as modelling "this node requires sensor_msgs/Image input at 10 Hz", which seems to be more like what you're after.

But by virtue of those specific packages being deployed together, ..