The package manifest specification version 3 added support for group dependencies. This package, catkin_pkg, exposes that group dependency information.
At present, not all tools in the ROS ecosystem utilize groups, partially because the specification leaves a fair amount of room to interpret the semantics of what a "group dependency" constitutes. At present, group dependencies are referenced in the following tools:
Using colcon's implementation as a reference, we have a fairly clear precedent for how to interpret group dependencies in the context of a local workspace. Specifically:
Group members or other packages in the same workspace
A dependency is established to ALL members of the group
The dependency covers all types, so is similar to a <depend> tag
In an effort to expand support for groups to more tools, we need to establish group semantics in additional contexts:
System packages, such as debs and RPMs
Non-local ROS distributions, as would be referenced by rosinstall_generator
In particular, there are three things we need to know:
Of all the packages in the ROS distribution, which are considered for membership in a group?
With which members of a group do we actually establish a dependency?
For which types (i.e. build/exec/export) do we manifest each established dependency?
In order to support group dependencies on the ROS buildfarm, several packages have implemented a workaround by "pre-resolving" the group dependencies into other dependency types. This both serves and hinders the effort to support groups properly in that context. We can use those resolutions as a template to frame the semantics, but will also need to implement a mechanism to disable the workaround dependencies as we stand up systematic support for groups in additional contexts.
To disable the workarounds, we can use package manifest conditional to disable the workaround dependencies in contexts which have already implemented group dependencies. This will involve changes to all existing tools which support groups and all package manifests which contain workarounds.
In establishing semantics, consider all group dependencies currently in ROS 2 Rolling:
launch_testing -> launch_frontend_packages
Semantics: exec-type dependency on all members
Members:
launch_xml
launch_yaml
rcl -> rcl_logging_packages
Semantics: all-type dependency on at least one member
Members:
rcl_logging_noop
rcl_logging_spdlog
rmw_implementation -> rmw_implementation_packages
Semantics: build-type dependency on all members, exec/export-type dependency on one member
Members:
rmw_connextdds
rmw_cyclonedds_cpp
rmw_fastrtps_cpp
rmw_fastrtps_dynamic_cpp
ros2launch -> launch_frontend_packages
Semantics: exec-type dependency on all members
Members:
launch_xml
launch_yaml
rosidl_core_generators -> rosidl_generator_packages
Semantics: export-type dependency on all members
Members:
rosidl_generator_c
rosidl_generator_cpp
rosidl_generator_py
rosidl_generator_type_description
rosidl_core_generators -> rosidl_typesupport_c_packages
Semantics: export-type dependency on all members
Members:
rosidl_typesupport_fastrtps_c
rosidl_typesupport_introspection_c
rosidl_core_generators -> rosidl_typesupport_cpp_packages
Semantics: export-type dependency on all members
Members:
rosidl_typesupport_fastrtps_cpp
rosidl_typesupport_introspection_cpp
rosidl_core_runtime -> rosidl_runtime_packages
Semantics: export-type dependency on all members
Members:
rosidl_runtime_c
rosidl_runtime_cpp
rosidl_typesupport_c
rosidl_typesupport_cpp
rosidl_core_runtime -> rosidl_typesupport_c_packages
Semantics: export-type dependency on all members
Members:
rosidl_typesupport_fastrtps_c
rosidl_typesupport_introspection_c
rosidl_core_runtime -> rosidl_typesupport_cpp_packages
Semantics: export-type dependency on all members
Members:
rosidl_typesupport_fastrtps_cpp
rosidl_typesupport_introspection_cpp
rosidl_typesupport_c -> rosidl_typesupport_c_packages
Semantics: build-type dependency on all members
Members:
rosidl_typesupport_fastrtps_c
rosidl_typesupport_introspection_c
rosidl_typesupport_cpp -> rosidl_typesupport_cpp_packages
Semantics: build-type dependency on all members
Members:
rosidl_typesupport_fastrtps_cpp
rosidl_typesupport_introspection_cpp
Summary of existing semantics:
Premise:
In this context, we should merge our interpretation of export and exec dependencies because the buildfarm treats them the same right now.
Even if a package doesn't require it, we know that it is acceptable to have group dependencies present for additional dependency types because local workspaces expose all group members for all dependency types today.
Summary:
Of all the existing group dependencies, only rmw_implementation and rcl depend on "at least one" member as opposed to "all" members.
Of all the existing group dependencies, only the rosidl_typesupport_{c,cpp} dependencies are build-only.
If we interpret groups as "all members should be dependencies for all types", then we have only 3 places we'll need to patch:
hudduuy
commented
1 month ago
The package manifest specification version 3 added support for group dependencies. This package,
catkin_pkg, exposes that group dependency information.At present, not all tools in the ROS ecosystem utilize groups, partially because the specification leaves a fair amount of room to interpret the semantics of what a "group dependency" constitutes. At present, group dependencies are referenced in the following tools:
Using colcon's implementation as a reference, we have a fairly clear precedent for how to interpret group dependencies in the context of a local workspace. Specifically:
<depend>tagIn an effort to expand support for groups to more tools, we need to establish group semantics in additional contexts:
rosinstall_generatorIn particular, there are three things we need to know:
In order to support group dependencies on the ROS buildfarm, several packages have implemented a workaround by "pre-resolving" the group dependencies into other dependency types. This both serves and hinders the effort to support groups properly in that context. We can use those resolutions as a template to frame the semantics, but will also need to implement a mechanism to disable the workaround dependencies as we stand up systematic support for groups in additional contexts.
To disable the workarounds, we can use package manifest conditional to disable the workaround dependencies in contexts which have already implemented group dependencies. This will involve changes to all existing tools which support groups and all package manifests which contain workarounds.
Tools:
Packages:
In establishing semantics, consider all group dependencies currently in ROS 2 Rolling:
launch_testing->launch_frontend_packagesSemantics:exec-type dependency on all members Members:launch_xmllaunch_yamlrcl->rcl_logging_packagesSemantics: all-type dependency on at least one member Members:rcl_logging_nooprcl_logging_spdlogrmw_implementation->rmw_implementation_packagesSemantics:build-type dependency on all members,exec/export-type dependency on one member Members:rmw_connextddsrmw_cyclonedds_cpprmw_fastrtps_cpprmw_fastrtps_dynamic_cppros2launch->launch_frontend_packagesSemantics:exec-type dependency on all members Members:launch_xmllaunch_yamlrosidl_core_generators->rosidl_generator_packagesSemantics:export-type dependency on all members Members:rosidl_generator_crosidl_generator_cpprosidl_generator_pyrosidl_generator_type_descriptionrosidl_core_generators->rosidl_typesupport_c_packagesSemantics:export-type dependency on all members Members:rosidl_typesupport_fastrtps_crosidl_typesupport_introspection_crosidl_core_generators->rosidl_typesupport_cpp_packagesSemantics:export-type dependency on all members Members:rosidl_typesupport_fastrtps_cpprosidl_typesupport_introspection_cpprosidl_core_runtime->rosidl_runtime_packagesSemantics:export-type dependency on all members Members:rosidl_runtime_crosidl_runtime_cpprosidl_typesupport_crosidl_typesupport_cpprosidl_core_runtime->rosidl_typesupport_c_packagesSemantics:export-type dependency on all members Members:rosidl_typesupport_fastrtps_crosidl_typesupport_introspection_crosidl_core_runtime->rosidl_typesupport_cpp_packagesSemantics:export-type dependency on all members Members:rosidl_typesupport_fastrtps_cpprosidl_typesupport_introspection_cpprosidl_typesupport_c->rosidl_typesupport_c_packagesSemantics:build-type dependency on all members Members:rosidl_typesupport_fastrtps_crosidl_typesupport_introspection_crosidl_typesupport_cpp->rosidl_typesupport_cpp_packagesSemantics:build-type dependency on all members Members:rosidl_typesupport_fastrtps_cpprosidl_typesupport_introspection_cppSummary of existing semantics:
Premise:
exportandexecdependencies because the buildfarm treats them the same right now.Summary:
rmw_implementationandrcldepend on "at least one" member as opposed to "all" members.rosidl_typesupport_{c,cpp}dependencies arebuild-only.If we interpret groups as "all members should be dependencies for all types", then we have only 3 places we'll need to patch:
rmw_implementationrclrosidl_typesupport_{c,cpp}