Rust battery packs aim to simplify crate choices

Picking crates is one of the first frictions new Rust users hit, and a new idea called battery packs is meant to reduce that overhead without creating lock-in. In a blog post, Niko Matsakis describes battery packs as curated sets of crates organized around a theme, with early examples for CLI, backend web services, embedded development, and error handling.

The concept is deliberately lightweight. A battery pack is essentially a list of recommended crates, so developers can swap out any choice later. Matsakis says there is already a working prototype: install it with cargo install cargo-bp, then use commands such as cargo bp list to browse available packs and cargo bp add cli to add a set of CLI-related libraries. A more complex demo, cargo bp add embedded, is based on the Embedded Working Group’s Awesome Rust repository.

A key part of the proposal is that anyone can publish a battery pack. They are distributed as crates named X-battery-pack, where dependencies express the maintainer’s recommendations, features define common sets of crates, and examples act as templates. That differs from earlier ideas for an extended Rust standard library by pushing curation out to communities that actually build in a given area, from general backend services to highly constrained no-std embedded targets.

Recommended reading

McIntosh’s $15,000 MX124 packs 13.4 channels and 7 HDMI inputs

Beyond dependencies

Battery packs are not limited to dependencies. They can also install recipes and templates. Matsakis points to a CI battery pack, proposed and developed by Jess Izen, that can configure a project with prebuilt GitHub Actions workflows via cargo bp add ci. The current implementation uses minijinja as a lightweight template system, though he suggests that part may grow over time.

Battery packs can also impose structure on choices. Instead of a flat list, they can group options into categories and mark them as pick at most one or pick any number. In the embedded example, that means developers can select a single concurrency framework such as embassy or rtic, while mixing in multiple drivers, display libraries, or hardware abstraction layers for targets like esp32, nrf52840, rp2040, or stm32f0.

Funding and ecosystem coordination

Matsakis argues the idea could do more than help newcomers. He says working groups in the Rust Commercial Network could publish battery packs reflecting the dependencies they actually use, turning those packs into a focal point for funding maintenance. His proposal includes an associated ecosystem fund for sponsored battery packs, where companies or individuals could support maintainers in exchange for benefits such as early patches or security disclosures.

He also frames battery packs as a possible way to improve interoperability. One example is async runtimes: while tokio is widely used, some large companies rely on internal runtimes, and crates often end up defining their own compatibility traits. A neutral, sponsored battery pack could provide a home for that kind of shared work.

Matsakis also acknowledges the risks. If anyone can publish a battery pack, the ecosystem could end up with too many of them. He argues that a few obvious starting points would likely emerge, while niche packs could still serve specialized communities. He is also explicit that battery packs should not freeze the ecosystem in place: because projects depend on the underlying crates, not the battery pack itself, a pack can evolve from one recommendation to another without breaking existing users. He cites Rust CLI parsing as an example of that kind of evolution, from docopt to clap to structopt, with structopt now folded into clap.

The broader argument is the same one Rust has long made for itself: keep the standard library small, bet on the ecosystem, and add structure only when the ecosystem grows large enough that tacit knowledge becomes a barrier. Matsakis says crates.io may have reached that point.