An invitation to Rust maintainers

A few weeks ago, we at Determinate Systems released Riff, a tool that uses Nix to automatically provide external dependencies for Rust projects. By that we mean dependencies written in other languages—like OpenSSL or the Protobuf compiler—that by definition can’t be installed by Cargo. The developer experience of Rust is widely regarded as one of the best in the business—and we concur!—but external dependencies have been a thorn in the side of the Rust community from the get-go. And so we’re excited to provide a full-fledged solution to this problem in the form of Riff.

The response thus far has been quite enthusiastic, with users on Twitter, Reddit, Hacker News, and other forums expressing variations of “magic!” and “finally!” (mixed with some quite reasonable critique, of course). We’d like to follow up on the initial launch by calling upon Rust project maintainers to support Riff in their projects. As you’ll see in this post, supporting Riff is easy, non intrusive, and of benefit not just to devs that directly depend on your project but rather to the whole Rust ecosystem.

How to support Riff in your Rust project

To give an example, let’s say that we’re creating a game engine in Rust called gam3r. Like many game engines, gam3r has some external—that is, non-Rust—dependencies that need to be installed in the current environment. More specifically:

• On all systems, protoc, the Protocol Buffers compiler, needs to be installed at build time.
• On macOS systems, both Intel (x86_64) and Apple Silicon (aarch64), Apple’s CoreServices framework needs to be installed.

Adding this to your Cargo.toml config would notify Riff to install these dependencies:

1
[package.metadata.riff]
2
build-inputs = ["protobuf"]
3

4
[package.metadata.riff.targets.aarch64-apple-darwin]
5
build-inputs = ["darwin.apple_sdk.frameworks.CoreServices"]
6

7
[package.metadata.riff.targets.x86_64-apple-darwin]
8
build-inputs = ["darwin.apple_sdk.frameworks.CoreServices"]

With this metadata in place, Riff knows that it needs to install these tools not just in gam3r but also in any project that depend on gam3r, no matter how far down the dependency tree gam3r is. The implication is that the more depended upon gam3r becomes, the more beneficial our Riff metadata becomes. For more in-depth instructions on adding Riff metadata, see our official docs .

If we neglect to provide that metadata, commands like riff run cargo build are far more likely to fail on downstream projects, shifting the burden to maintainers of those projects to provide Riff metadata. But adding this small handful of lines to our Cargo.toml improves the chances that riff run and riff shell on downstream projects will Just Work™️, thereby eliminating those small bits of misdirected time and effort that really add up on an ecosystem level.

Our goal

Our end goal is to enable Riff to build and/or run 100% of Rust projects. Is that truly achievable? This will depend on you all as Rust maintainers, of course, but we’re confident that Riff, with proper buy-in, has the potential to positively obliterate the external dependency problem in Rust (and in other languages later).

We believe that every time a Rust project with external dependencies—and that’s the lion’s share of heavily depended-upon Rust projects—is made “Riffable,” the already-thriving Rust ecosystem takes a small step forward and asymptotically approaches a state where riff shell and riff run become second nature. We cordially invite all Rust maintainers to help us get there.