Recommend colcon-cargo-ros2 as simplified alternative to current build setup

[jerry73204]

The current setup requires boilerplate to support Rust packages in ROS. It requires:

• Installing colcon-cargo, colcon-ros-cargo and cargo-ament-build.
• The manual configuration to include dependent message packages in ROS workspace
• Maintain a .cargo/config.toml to locate Rust bindings.

I would recommend my colcon-cargo-ros2. It avoids all boilerplate mentioned above. Users simply pip-install it and the colcon build just works. The binding generation is embedded in it and it targets rclrs 0.6 on crates.io. We already tested a complex LCTK project using both Rust and ROS.

pip uninstall colcon-cargo colcon-ros-cargo  # Remove conflicting packages
pip install -user colcon-cargo-ros2

colcon build --cargo-args --release

It provides additional benefits over current method.

• Support zero configuration. No .cargo/config.toml file. No manual message dependency management.
• Work with any Rust workspace hierarchy.
• Efficient binding generation process. The bindings for each msg package is generated once in one colcon build.
• Performance. The colcon-cargo-ros2 is mostly implemented in Rust except the colcon facing parts.

I sincerely ask if you can look into it and see if could be an official alternative to colcon-cargo.

[esteve]

Thanks for the recommendation. I had a look at the project and while it seems an interesting alternative, I've noticed it's a fork of colcon-ros-cargo you created two weeks ago, it'd have been useful for us if those changes were contributed upstream instead of creating a separate project. Or at least create issues in the colcon-ros-cargo project so that we know what needs to be improved.

[esteve]

@jerry73204 anyway, would you be interested in contributing your changes to colcon-ros-cargo? One big issue is that we might actually want to remove the Rust parts of the build process (cargo-ament-build) because right now it's difficult to distribute Rust code as part of ROS, and we had discussed to replace that with Python.

[mxgrey]

Adding to Esteve's comments, this general topic of colcon's relationship with message bindings is one of the most complex problems that we regularly discuss at the ROS2-Rust working group meetings. If you're interested in this topic @jerry73204 then I would highly encourage you to join those discussions. That's going to be the most effective way to influence how we approach this problem as a project.

One example of a red flag that I see in your README is this:

Configures Cargo: Updates each package's .cargo/config.toml with patches

Some packages have .cargo/config.toml files committed to their version control, so modifying that config file in-source will create problems for those projects.

There may be other subtle implementation details that create conflicts with various usage patterns. We use the working group meetings to rapidly explore the murky solution space and identify this type of problem by having people with many different perspectives present at the same time.

[azerupi]

@mxgrey sorry I don't want to hijack this PR thread, but I found your comment relevant to an issue we have been facing with the .cargo/config.toml at the root of the workspace with Cargo.lock files. We were also considering using a .cargo/config.toml per package but your comment about packages already using a .cargo/config.toml is valid. Anyway, I created this issue https://github.com/colcon/colcon-ros-cargo/issues/37 where we can have further discussion.

[luca-della-vedova]

One example of a red flag that I see in your README is this:

Configures Cargo: Updates each package's .cargo/config.toml with patches

Some packages have .cargo/config.toml files committed to their version control, so modifying that config file in-source will create problems for those projects.

To echo this, I believe from discussions with @cottsay that one of the non-negotiables of colcon is that it will not touch your src directory in any way. Since this approach breaks this assumption I feel it might be hard to get buy-in from the colcon team, which is necessary if we want this to become an official extension that is packaged and distributed by them.

[jerry73204]

Thanks you all. Your comments can help improve the colcon-cargo-ros2.

@azerupi @luca-della-vedova as you mentioned the .cargo/config.toml placement issue, the colcon-cargo-ros2 v0.3.x already replaces it with an implicit --config override. The README.md shows the outdated information. This design needs deeper inspection in the practical sense. You can check my comment in colcon/colcon-ros-cargo#37.

@esteve I'm pleased to contribute to colcon-ros-cargo. The reason that led to the embedded Rust library design is mostly due to the performance on very large ROS project based on my past experience. I believe colcon-cargo-ros2 already addresses the code distribution concern that you mentioned, as it already provides multi-platform wheel builds on PyPI. We can move to colcon/colcon-ros-cargo#38 for further discussion.