Using Rust Workspaces

Overview

A cargo workspace is a multi-crate composition with one Cargo.lock, one target/, one resolver, and one set of dependency versions. Treat it as a system or it calcifies into a federation of crates that disagree about versions, lints, licences, and which traits are public.

This pack treats workspace scope as a discipline distinct from single-crate engineering. A real workspace makes system-level decisions before per-crate ones: which crates exist and why (structure), which dependency versions every crate sees (workspace.dependencies + resolver-2 semantics), what lint policy applies uniformly (workspace.lints + workspace-scope clippy.toml), what supply-chain rules govern the whole graph (deny.toml), where the public surface ends and the implementation crates begin (visibility), and which compositional shapes never work and have to be refused at intake (anti-patterns).

This is the workspace-scope counterpart to axiom-rust-engineering:

• axiom-rust-engineering is single-crate-shaped — borrow checker, traits, async, clippy on one crate, cargo audit on one Cargo.toml, cargo profile on one binary. Its audit and delint commands compose at workspace scale, but the sheets assume one crate's perspective.
• axiom-rust-workspaces (this pack) is multi-crate-shaped — the [workspace] root, workspace.dependencies propagation, workspace.lints inheritance, deny.toml over the union of crate trees, the public/internal crate split. The unit of analysis is the workspace, not the crate.
• The two pair: rust-engineering's per-crate rigour applies to each crate in a workspace; this pack governs how those crates compose. A workspace whose individual crates are clean but whose composition is broken (drift, leaky internals, feature blowup) needs both packs.

When to Use

Use this pack when: