we had a discussion in the Rust WG meeting about what it means for a client library to become official and what it needs to comply with in order to achieve such status.
To start with, for us, to become an official client library it means that it’s being included in the default set of packages when someone installs ROS 2, it’s referenced in the documentation (e.g. examples are provided not only for C++ and Python, but also for this new library), etc.
Right now, only rclpy and rclcpp are referenced in the documentation, which are also maintained by the core ROS 2 team. Is that a requirement for any library? Can libraries be official, but not maintained by the core ROS 2 team? We see this in other projects (e.g. ros-planning has its own maintainer team, but it’s regarded as the official umbrella for motion and navigation planning).
However, client libraries can also be argued to be part of the ROS 2 core, so here’s where our doubts come from.
This comes from specific dicussion in the Rust WG as to how much rclrs (our Rust client library) needs to resemble rclcpp and rclpy for it to be considered as a candidate to be included in the stadard ROS 2 distribution. There are aspects of C++ and Python that either can’t be translated into Rust (e.g. no inheritance means no components in the way that rclcpp/rclpy do composition) or that some APIs can be better done differently (e.g. if we invert the relationship between nodes and executors we can take advantage of Rust’s ownership model).
Another example, we decided to use the ROS 2 message generation infrastructure for rclrs so that it’d be familiar, but perhaps that’s not even necessary for rclrs to become an official client library and we could leverage more from the Rust world instead of continuing with our mix of Python, C and Rust.
Anyway, with this discussion we’d like to formalize this criteria and perhaps lead to a REP that can be used as a reference for future client libraries.