Such test should include the following step:

• Create a template ws/src/ directory with a minimal rust package (hello-world)
• Run colcon (with the colcon-cargo extension enabled) from the root of the workspace and make sure that the appropriate binaries are generated under the rust package install prefix; Potentially also execute the installed executable

Calling colcon test should generate xml report with information about passed/failed tests.
Otherwise colcon test-result --all is not able to give information about rust tests.

The only solution I found is:

• install a modified version of cargo-test-junit (https://github.com/voop/cargo-test-junit)
• modify colcon-cargo to call cargo test-junit (petrikvladimir@d24ce16)
• then I was able to setup travis CI: (https://github.com/voop/rosrust_tests)

Is there a nicer way how to get test-results ?

The cargo extensions for colcon are very important if the ROS community is to benefit from the growing Rust ecosystem.

Unfortunately these extensions have been unmaintained for a while, as there are several small but crucial bug fixes that have been sitting in PRs for months without review.

I'd like to request committer status for myself to help move these PRs along. It would also be good to get committer status on colcon-ros-cargo so I can help there as well.

And to avoid a bus factor of 1, I would also recommend committer status for @luca-della-vedova who is also working very actively on bringing ROS and Rust together.

Once we're happy with the feature set, we should release colcon-cargo into PyPI

Particularly, when colcon-cargo is fully integrated into colcon test, it would be a good time for a release

Firstly, much thanks to the developers and maintainers for getting this plugin started! I'm very excited by the prospect of using Rust in ROS2, and more generally having a nice automated workspace overlay tool for Rust.

After trying out the tool, I noticed that Rust library packages seem to explicitly not be supported. Trying to include a library package, I get the following error message:

error: no packages found with binaries or examples

I assume this is an intentional limitation, since it currently seems quite difficult to have Cargo redirect to a local dependency without modifying the Cargo.toml of the package that needs to use the local dependency.

While researching how we might be able to make libraries and dependency overlays work I learned about Cargo config files which (will) offer a patch-in-config feature. This allows a [patch] section to be put into a .cargo/config.toml file, and those dependency patches will be applied to every package that belongs to the workspace that the config file is provided for. This feature is currently in the beta channel (version 1.56), which looks like it will move to stable on Oct 21.

I just did a quick manually set-up test of this with the following structure (relative to the root of a hypothetical colcon workspace):

.cargo/config.toml:

[patch.crates-io]
hello_lib = {path = "src/hello_lib"}

src/hello_lib/Cargo.toml:

[package]
name = "hello_lib"
version = "0.1.0"
edition = "2018"

src/hello_lib/src/lib.rs:

pub fn say_hello() {
    println!("Hello, library!");
}

src/hello_app/Cargo.toml:

[package]
name = "hello_app"
version = "0.1.0"
edition = "2018"

[dependencies]
hello_lib = "*"

src/hello_app/main.rs:

use hello_lib;

fn main() {
    hello_lib::say_hello();
}

Then run the following command from src/hello_app:

cargo +beta run

You should find that the hello_app successfully builds, runs, and prints out Hello, library!. (Make sure you have run rustup install beta and rustup update before running the command.)

I think this would be a solid strategy for fully integrating Cargo into colcon. The documentation for this feature explicitly mentions that the feature is intended for external build tools (such as colcon):

Patching through cargo configuration files is generally only appropriate when the patch section is automatically generated by an external build tool.

Does anyone have thoughts on this? It's exciting to think that we might be able to have complete colcon+cargo integration in just a few weeks when this feature goes stable.

Currently each developer has to setup flake8 on their own and look into the test_flake8.py for what rules should be ignored and what files to run it on.

Unrelated to this but, @dirk-thomas what's your opinion about switching to black or leave it up to each extension to decide the formatter/linter of choice?

I've used black consistently, it has excellent editors support and I haven't seen any notable bug when using it. It can be used both as a linter or as a formatter, and we can also lose the test_flake8.py file as well.

I have noticed that at times changes to the source code within the Rust projects won't "propagate" to the wider ROS 2 system unless I delete the target directories within each of the crates I'm working on.

Is this something that colcon-cargo can do automatically? Or is this a bug within colcon-cargo?

Rust workspace shall be ignored when browsing Rust packages.
Currently it crashes either because Cargo.toml in case of a workspace directory does not contains dependencies or because an empty dependency is not allowed.
We may check Cargo.toml file, if it is a worskpace one, skip current dir.

I'm trying to write a pure Rust package and build it in a colcon workspace. However, I can't seem to add a basic package.xml without colcon thinking it somehow deals with Cmake:

colcon build --symlink-install --packages-select bbr_cli
Starting >>> bbr_cli 
--- stderr: bbr_cli
CMake Error: The source directory "/home/ruffsl/ws/bbr_ros2/src/bbr_ros2/bbr_cli" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
---
Failed   <<< bbr_cli	[ Exited with code 1 ]

Summary: 0 packages finished [0.22s]
  1 package failed: bbr_cli
  1 package had stderr output: bbr_cli

Having the colcon-cargo extension installed, the cargo project seems to build fine without a package.xml but if I add a skeleton package.xml like so, I get the error above:

<?xml version="1.0"?>
<package format="2">
  <name>bbr_cli</name>
  <version>0.0.1</version>
  <description>Command Line Interface for BBR</description>
  <maintainer email="[email protected]">Ruffin White</maintainer>
  <license>Apache License 2.0</license>

</package>

cc @lelongg