Moveit Dependency and Build Target Lists Don't Match

[Bckempa]

Discovered while investigating #228, the method of cloning the moveit2 repo into the workspace leads colcon to try and build packages that are not passed to rosinstall_generator for dependency resolution.

There are minor compilations and limitations with various methods of resolving this which were discovered during that investigation. This issue tracks the selection and implementation of resolving this mismatch between the dependency resolution and build phases. It may be dependent on a scope-cleanup of the moveit container as well.

Starting with ref_utils

The package is missing from the image .repos file generated with

rosinstall_generator
    --rosdistro ${ROS_DISTRO}
    --deps
    --exclude-path ${SPACEROS_DIR}/src
    --exclude $(cat excluded-pkgs.txt) 
    -- $(cat moveit2-pkgs.txt) > moveit2_generated_pkgs.repos

But listed correctly when explicitly prompted by key:

rosinstall_generator
    --rosdistro ${ROS_DISTRO}
    --deps
    --exclude-path ${SPACEROS_DIR}/src
    --exclude $(cat excluded-pkgs.txt) 
    -- moveit_ros_trajectory_cache

Now I see that colcon is trying to build packages from the GitHub checkout of moveit that aren't listed in moveit2-pkgs.txt and therefore not considered by rosinstall. We have several options to fix that.

Verified by using the colcon package list as rosinstall_generator target input which correctly identifies rmf_utils as a dependency:

rosinstall_generator
    --rosdistro ${ROS_DISTRO}
    --deps
    --exclude-path ${SPACEROS_DIR}/src
    -- $(colcon list -n)

Originally posted by @Bckempa in #228

[ivanperez-keera]

What's the success criteria here? How can we check that this is accomplished?

[Bckempa]

The long term result is we need a principled way of selecting the package and skip lists, tooling to automatically flag when they fall out of date, and potentially some feature additions to the infrastructure tooling but I tired to break all that up into some of the smallest, most actionable steps.

In this case we probably need to add the --deps-only flag which could break some down-stream demos that expected the incorrect behavior (relevant XKCD) so we'd then need to decide which of those packages get added back explicitly to this layer v.s. fixed on the consuming side.