Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expanded Support for Group Dependencies #369

Open
cottsay opened this issue Apr 23, 2024 · 1 comment
Open

Expanded Support for Group Dependencies #369

cottsay opened this issue Apr 23, 2024 · 1 comment
Assignees

Comments

@cottsay
Copy link
Member

cottsay commented Apr 23, 2024

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:

  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:

Packages:

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
Copy link

hudduuy commented May 23, 2024

very good job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants