Expanded Support for Group Dependencies

[cottsay]

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:

• colcon-ros
• ros_buildfarm (currently disabled in production)

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:

1. Of all the packages in the ROS distribution, which are considered for membership in a group?
2. With which members of a group do we actually establish a dependency?
3. 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.

Tools:

• Add logic for excluding group workaround dependencies colcon/colcon-ros#155
• Add logic for excluding group workaround dependencies ros_buildfarm#1040

Packages:

• launch_testing
• rcl
• rmw_implementation
• ros2launch
• rosidl_core_generators/rosidl_core_runtime
• rosidl_typesupport_c/rosidl_typesupport_cpp

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:

• rmw_implementation
• rcl
• rosidl_typesupport_{c,cpp}

[hudduuy]

very good job!