Distribute mcap cli as .deb package

[amacneil]

Description

ros2 bag CLI is great for recording and playback of MCAP files. However, the mcap CLI is the best way to manipulate MCAP files (split, merge, doctor, fix, etc).

Installing rosbag2_storage_mcap should make the mcap CLI available within the ROS workspace. We should install mcap CLI to the ROS workspace rather than /usr/bin, because multiple ROS packages (for different distributions) may be installed in parallel, and the user may install mcap to /usr/bin via another method too (e.g. an mcap ppa in the future).

Desired workflow

$ apt install ros-humble-rosbag2-storage-mcap
$ source ./install/setup.bash
$ mcap version
v0.0.11

[defunctzombie]

Emerson: "I don't think it will be very hard"

[amacneil]

@jhurliman pointed out that this should probably be a separate package, as people might not want it installed during runtime on robots

[jhurliman]

Since this ticket has evolved into "Distribute mcap cli as a .deb package", I think it should be moved to the foxglove/mcap repo. Being able to run apt install mcap would be useful to folks outside of the ROS ecosystem, so distributing the .deb via ROS package repositories might not be the right move. We have the package repository used to distribute Foxglove Studio, and/or we could look at submission to Ubuntu/Debian.

[amacneil]

I don't know what the timeline for getting a package into debian is, but it may be significantly simpler/faster to distribute the mcap cli with this plugin (as something that gets sourced into your path with setup.bash), even if we make a general purpose .deb in the future.

[amacneil]

I created foxglove/mcap#675 as a separate ticket.

@jhurliman after your mcap talk I am back to the opinion that rosbag2_storage_mcap should distribute the mcap CLI by default, and add it to your PATH via normal ROS setup.bash. The mcap cli is pretty important to many mcap workflows and having a good out of the box experience is important.

We should add it to Debian universe as well, but that is useful to a different set of people.

[clalancette]

The mcap cli is pretty important to many mcap workflows and having a good out of the box experience is important.

We should add it to Debian universe as well, but that is useful to a different set of people.

I will say to be careful with this. If you have it in both places, they inevitably get out of sync, and then you'll have people installing one but expecting the other to work (we have this problem with catkin-pkg). That's not to say you shouldn't do it, and I don't have any specific recommendations about how to make it easier. But I just wanted to make you aware of what you'll be signing for.

[defunctzombie]

I will say to be careful with this. If you have it in both places, they inevitably get out of sync, and then you'll have people installing one but expecting the other to work (we have this problem with catkin-pkg). That's not to say you shouldn't do it, and I don't have any specific recommendations about how to make it easier. But I just wanted to make you aware of what you'll be signing for.

Could we limit the one we install with the mcap package to a ros2 tooling command? i.e. ros2 mcap info ... and the system one would be mcap. That might still be confusing.

@amacneil A counter argument: I want to keep what I install on my robot for recording focused on recording rather than other post-processing workflows and random tools. The mcap CLI is a tool for post processing and not recording so it should be in a separate package. It's hard to dispute "having a good out of the box experience" as being important - tho it is useful to consider package scope and purpose. The primary purpose is to provide the storage plugin to read/write mcap files via the storage interface.

[MichaelOrlov]

IMO. The mcap CLI could be as a separate package, but it's highly desirable to be bundled with rosbag2 if we are going at least bundle rosbag2_storage_mcap plugin in rosbag2.

[defunctzombie]

but it's highly desirable to be bundled with rosbag2

@MichaelOrlov Does this mean you are in favor of making rosbag2_storage_mcap depend on this separate package? Or are you proposing some different package setup to include the mcap cli?

[MichaelOrlov]

@defunctzombie What ever. Just to make mcap CLI available with rosbag2 by default.

[amacneil]

Installing it as a ros2 mcap command might be a good option to avoid conflict with an Ubuntu universe debian package.

I personally think the developer experience of having the CLI available by default is more important than the reduced footprint of one less binary on the robot, given how much else ROS installs.

But if people feel strongly about reduced runtime robot footprint, then here is a concrete proposal:

• New mcap_cli package that installs the ros2 mcap subcommand.
• Make the mcap_cli package a dependency of rosbag2 metapackage (but not a dependency of rosbag2_storage_mcap), so that it is installed by default (see existing rosbag2 dependencies)
• People who do not want the mcap CLI can install the specific dependencies of rosbag2 metapackage that they need (as they presumably would already be doing if they care about minimizing on-robot footprint)

[jhurliman]

The proposal LGTM. I feel strongly that you should not be forced to install a binary unrelated to recording when you install the specific mcap recording package, but installing it with the rosbag2 meta package makes sense to me.

[james-rms]

Moving discussion over to foxglove/mcap#755