Process for third-party client libraries to be incorporated into the core ROS 2 distribution

[esteve]

@clalancette

So before we talk about the getting ros2-rust into the core, we need to make sure it is releasable into the ROS ecosystem at all. That is currently not the case for any Rust packages.

Of course! Hence why I started this thread, so we can figure out what something like this would involve, it’s never too early to talk.

Moreover, I’m interested not only in what the buildfarm infrastructure needs, but what would the expectations for a third-party package would be before it’s considered for inclusion into the core. For example, what minimum features it should have, whether or not OR would be involved in it, if the members of the team behind it must belong to different organizations, etc.

For reference, the incubation process for an Apache project (e.g. Incubation Status File · apache/superset Wiki · GitHub), has certain requirements at the project management level for a project to be accepted into Apache.

@clalancette

If you are interested in pushing forward on this, then I’ll point you to @nuclearsandwich , who has been thinking about this problem and probably has a much better idea of what would need to be done.

Awesome! @nuclearsandwich do you have a document, a ticket or maybe perhaps just post here what you’ve found so far? Thanks.

I’d add, though, that we follow pretty much all the ROS conventions for building packages. We have colcon extensions for cargo and ament_cargo build types, so that ros2-rust (and packages that depend on it) can be built via colcon. We could start by releasing these two as part of python3-colcon-common-extensions.

@clalancette

Once we can release and CI ros2-rust at all, we can consider whether it makes sense to put it into the core.

ros2-rust is divided into a client library and a code generator. The code generator follows a similar process as the C++ and Python generators, i.e it’s written in Python and leverages rosidl and all the related packages. One difference here is that unlike the Python generator, there’s no C layer in between rosidl_typesupport and the Rust messages (the generator only spits out .rs files), and these are only compiled at the very last stage (i.e. when an application depends on these, but not when the message packages are built).