provide a ros-dev-tools package

[christian-rauch]

The ROS 2 Deban repo contains a convenient ros-dev-tools metapackage that installs all development tools.

The RoboStack instructions currently list packages:

micromamba install -c conda-forge compilers cmake pkg-config make ninja colcon-common-extensions catkin_tools rosdep

It would also be convenient to have such a "ROS dev tools" meta package in RoboStack to install all these tools that are required to build a workspace from source.

Also, it seems that these tools are installed in the base environment and not inside the ROS environment. E.g. micromamba env -n base export will list colcon packages etc. Is this intended? The instructions in the beginning rightfully say that "Do not install ROS packages in the base environment". If it is intended to install the development tools, including colcon, in the base environment, the instructions should maybe mention that these tools are indeed installed in base.

[traversaro]

Also, it seems that these tools are installed in the base environment and not inside the ROS environment. E.g. micromamba env -n base export will list colcon packages etc. Is this intended?

No, the tools should be installed in the earlier created ros_env environment, exactly like the earlier mamba install ros-kilted-desktop is meant to be executed there. If that is not clear probably we need to clarify that.

The ROS 2 Deban repo contains a convenient ros-dev-tools metapackage that installs all development tools.
It would also be convenient to have such a "ROS dev tools" meta package in RoboStack to install all these tools that are required to build a workspace from source.

Interesting, I was not aware of that, related discussions for reference:

• https://discourse.openrobotics.org/t/ros-developer-tools-now-in-binary-form/29802
• Add ros-build-essential and ros-dev-tools variants. ros-infrastructure/infra-variants#1

It probably make sense to do that. As those packages are not using package.xml and are not named ros-<distroname>-<pkgname>, we need to understand where in the pipeline we should generate this packages. We already added support in vinca for generating the special "ros2-distro-mutex" package in RoboStack/vinca#79 . Probably we could add a infra_variants_packages to mirror the content of https://github.com/ros-infrastructure/infra-variants (even if I am not super-excited to duplicate the data across distros, but that's probably the easiest option). One thing to note that several tools that we do not currently installed are installed by the metapackage, see https://github.com/ros-infrastructure/infra-variants/blob/316bc45f6d870a661132bc7af1e4d7ecf58360f7/ros-build-essential/ros-build-essential.spec#L11-L36, so we should try to match the existing packages as much as possible.

[traversaro]

Probably we could add a infra_variants_packages to mirror the content of https://github.com/ros-infrastructure/infra-variants (even if I am not super-excited to duplicate the data across distros, but that's probably the easiest option). One thing to note that several tools that we do not currently installed are installed by the metapackage, see https://github.com/ros-infrastructure/infra-variants/blob/316bc45f6d870a661132bc7af1e4d7ecf58360f7/ros-build-essential/ros-build-essential.spec#L11-L36, so we should try to match the existing packages as much as possible.

Beside distro duplication, the problem of that is that in that case we would need to completely manually manage the updates of the package. A possible alternative may just to package the packages in conda-forge, so we would at least get a automatic PR for every new tag in https://github.com/ros-infrastructure/infra-variants/tags.

[christian-rauch]

It probably make sense to do that. As those packages are not using package.xml and are not named ros-<distroname>-<pkgname>, we need to understand where in the pipeline we should generate this packages.

I would simply say that these meta packages should be generated where the other distro-independent tools packages, such as colcon, catkin, and rosdep, are generated.

[traversaro]

It probably make sense to do that. As those packages are not using package.xml and are not named ros-<distroname>-<pkgname>, we need to understand where in the pipeline we should generate this packages.

I would simply say that these meta packages should be generated where the other distro-independent tools packages, such as colcon, catkin, and rosdep, are generated.

Indeed, all of those are generated by conda-forge feedstocks:

• https://github.com/conda-forge/colcon-feedstock
• https://github.com/conda-forge/colcon-common-extensions-feedstock
• https://github.com/conda-forge/rosdep-feedstock
• https://github.com/conda-forge/catkin_pkg-feedstock

so it probably make sense to have a ros-infra-variants-feedstock.