search

ros-tooling / rosbag2_storage_mcap

rosbag2 storage implementation for MCAP file format
https://mcap.dev/
Apache License 2.0
32 stars 5 forks source link

Distribute mcap cli as `.deb` package #47

Closed amacneil closed 1 year ago

amacneil commented 2 years ago

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 commented 2 years ago

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

amacneil commented 2 years ago

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

jhurliman commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

I created https://github.com/foxglove/mcap/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

amacneil commented 1 year ago

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:

jhurliman commented 1 year ago

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 commented 1 year ago

Moving discussion over to https://github.com/foxglove/mcap/issues/755