.cargo/config.toml in ROS 2 workspace root causes issues with Cargo.lock files

[azerupi]

We have experienced a lot of pain with Cargo.lock files when working on our Rust packages in a ROS 2 workspace due to the shared .cargo/config.toml at the root of the ROS 2 workspace.

The issue that we are facing is that the .cargo/config.toml contains patch entries for all Rust packages that are present in the workspace and Cargo.lock files in each package end up containing entries for packages even if they are not a dependency in the form of unused patch entries.

[[patch.unused]]
name = "rcl_interfaces"
version = "2.0.3"

[[patch.unused]]
name = "rosgraph_msgs"
version = "2.0.3"

[[patch.unused]]
name = "sensor_msgs"
version = "5.3.6"

[[patch.unused]]
name = "test_msgs"
version = "2.0.3"

This means the lock files depend on the set of packages that are currently in my ROS 2 workspace and this can cause a lot of conflicts when working with different people that have different sets of packages in their workspace or even when working alone from different workspaces.

This issue was so bad for us that it forced us to remove our lock files from git because of all the merge conflicts.

Is there a way we can improve the situation? I was thinking of going in the direction of having one .cargo/config.toml for each package. But then I saw this comment ros2-rust/ros2_rust#553 (comment) with a valid reason not do that.

[jerry73204]

@azerupi I believe this issue relates to the way how Cargo resolve its dependencies and the the way it coops with Colcon. Cargo enforces that all deps in the Cargo workspace must be valid. It relies on the Colcon plugin to discover all related msg packages and generate bindings in anticipation. Colcon cannot call cargo metadata before all bindings are ready or it will break Cargo. In this way, Colcon has to search for Cargo workspace manifest and generate patches in .cargo/config.toml using custom logic. That comes the engineering complexity.

I believe it's intended behavior according to Cargo reference that Cargo unifies all discovered dependency versions. Hence, the Colcon has to ensure that all bindings packages ready in .cargo/config.toml. It causes the unused patches issue in your scenario.

Another concern is the placement of .cargo/config.toml as these files are necessary for Cargo to resolve deps. The first issue is that It would conflict with existing user configs. It puts absolute paths in configs within the source tree and that is undesired for management. The second issue is that Colcon cannot reply on Cargo to locate the proper workspace folder due to dep resolution issue.

One alternative approach is to pass implicit --config command-line override which is now implemented in colcon-cargo-ros2. It avoids adding .cargo/config.toml files. However, developers has to --config manually to cargo fmt, cargo clippy and alike. Some well-known extensions such as cargo nextest does not support the --config feature.

[sunshowers]

Hey, nextest maintainer here -- we definitely support Cargo's --config feature. If you see an issue please file a bug report :)

[maspe36]

Thank you for opening this issue, @azerupi. I hadn’t fully considered how our current patching approach breaks down in scenarios like the one you described.

Is there a way we can improve the situation?

I’ve been working on this area for years now, and there are still differing opinions on the best path forward. At the end of the day, the build tools have fundamentally conflicting philosophies, and that tension keeps surfacing here.

I think half of the solution is a “shim” crate—something conceptually similar to a -sys crate. I put together a full example, including a detailed README, here.

However, this still doesn’t fully address consuming message packages within the same workspace, nor custom message packages located in underlays.

One alternative approach is to pass implicit --config overrides…

I haven’t had a chance to dig into colcon-cargo-ros2 yet (it’s on my list as I work through these issues), but I know @cottsay explored something similar with pallet-patcher. My main concern with this direction is that we could end up passing dozens of --config flags. Cargo of course supports it, but it makes building directly with Cargo, without colcon, significantly harder. We now need to configure all of our local development tools to pass the same --config flags, its a chance for mistakes. I think ROS + Rust without great cargo integration is a huge miss. Cargo is a massive pull to Rust in my opinion.

If these types of discussions interest anyone, I encourage you to attend our monthly working group meetings where we discuss this at length. Here are our previous minutes, and our next meeting is scheduled for December 8th from 2 - 3pm UTC. There will be a post on the ROS discourse with the link to the google meet, or, you can find it on the OSRF Community Events Calendar.

---

Additional reading on this if you're extra interested

• Install a curated registry of crates with libraries colcon-cargo#67 (comment)
• https://internals.rust-lang.org/t/local-crate-registry-without-vendoring/23473

[luca-della-vedova]

I haven’t had a chance to dig into colcon-cargo-ros2 yet (it’s on my list as I work through these issues), but I know @cottsay explored something similar with pallet-patcher. My main concern with this direction is that we could end up passing dozens of --config flags. Cargo of course supports it, but it makes building directly with Cargo, without colcon, significantly harder. We now need to configure all of our local development tools to pass the same --config flags, its a chance for mistakes. I think ROS + Rust without great cargo integration is a huge miss. Cargo is a massive pull to Rust in my opinion.

I haven't been able to attend the discussions in some time but I thought an idea that surfaced in the past was to have a new colcon verb to generate the .cargo/config.toml files, I can imagine a case where there are two verbs for users that want cargo to keep working (names are random, not the time for bikeshedding!):

• colcon generate-cargo-config that generates a .cargo/config.toml in the root of the workspace as colcon-ros-cargo currently does. This has the benefit of not polluting source directories but generates the lock file issues + mountain of unused patch warnings.
• colcon generate-cargo-config --local that generates them in the src folder, useful for people that want to keep building with cargo and not have a mountain of warnings but will pollute your source folder.

Both options could support a --packages-select / --packages-up-to that would either add patch entries for all the packages to the root file (if generating a global .cargo/config.toml) or only generate config files in the requested packages.

Would this satisfy your need for a way for cargo developers to still be productive without having to rely on colcon?

[azerupi]

Hey everyone, thanks for the responses! I understand this is a thorny topic.

I think ROS + Rust without great cargo integration is a huge miss. Cargo is a massive pull to Rust in my opinion.

Absolutely, I wouldn't want to trade Cargo.lock support for straight cargo call support after first build. We use the direct cargo calls quite extensively during development for fast iteration times and testing.

However, this still doesn’t fully address consuming message packages within the same workspace, nor custom message packages located in underlays.

Yes, I don't think it would solve this specific issue because when adding a new package to the workspace it would still be written to all of the lock files of the other packages as a side effect even if they don't depend on that new package. And since we have one repo containing multiple packages this issue is exacerbated for us, causing lots of merge conflicts.

If these types of discussions interest anyone, I encourage you to attend our monthly working group meetings where we discuss this at length.

I will certainly join the next one. I didn't join the two previous one because they were not announced on discourse as far as I saw. Could I suggest to also publish a monthly reminder on matrix chat? 🙂

colcon generate-cargo-config --local that generates them in the src folder, useful for people that want to keep building with cargo and not have a mountain of warnings but will pollute your source folder.

That would be a perfectly acceptable solution for us. We use just to abstract over most of the colcon commands anyway and make it more user friendly for our workflow. So having this option would solve our issue while being transparent in our workflow.

Is there something we can do to help with this effort?