What's the best workaround for optional dev-dependencies?

I'm working on a relatively large project in robotics, and I'm using rubullet for doing some simple visualization and testing in sim in example binaries. It mostly works fine, but there are two issues:

  • rubullet compiles all of Bullet from scratch, which is rather time-consuming.
  • rubullet also only compiles on Linux. This is quite annoying, as I'd like to have CI results for all systems and architectures.
Why not use [other thing?] rubullet is not perfect. It's nigh-unmaintained and has some rough edges. I have a few other options, but I don't like any of them.
  • Expose Python bindings for my project and then use PyBullet for visualization. This is the most practical choice, but I don't want to have to introduce more dependencies and technologies if I can help it, at least for now. In the long run I will likely do this.
  • Fork rubullet and fix the issues. I wouldn't really mind doing this, but I don't have that much time on my hands.
  • Use Bevy+Rapier3d and make my own simulator. I would also love to to this, but I don't have six months to spare on a chase down a rabbit hole.

Currently, I have rubullet gated as a dev-dependency, as it isn't actually needed for my full crate.

[dev-dependencies]
rubullet = "0.1.0-alpha-3"

I'd like to disable rubullet on most builds, since it massively increases build time and doesn't work on every system. I can actually run most tests without it - I just use it for visual verification that trajectories are correct.

However, optional dev-dependencies don't seem to be particularly close to being usable. So I find myself in need of a workaround: how can I use rubullet in my personal Linux test examples without needing it everywhere?

Can you move the code which uses the big dependency to its own crate that depends on the main library? If that's acceptable, then create a separate package in the Cargo workspace. You can build/run it with the --package package_name argument (short form -p package_name).

cargo run -p sim_with_viewer

... or whatever you would like to call it.

This is a trick I picked up several years ago for very similar reasons, and it's been good to me.

2 Likes