Concepts
Overview
How rusty replaces cargo and rustup with a single content-addressable stack.
rusty combines three concerns that are usually split across rustup, cargo, and ad-hoc caching scripts:
- Toolchain management —
rusty env * - Package management — init, lock, fetch, build, test, add
- Caching infrastructure — global CAS, per-crate layers, artifact cache
Everything shares one data root (RUSTY_HOME, default ~/.rusty) and one project-local directory (.rusty/ per workspace).
Data flow
registry / git sources
│
▼
rusty fetch ──► CAS store (deduplicated blobs + crate tarballs)
│
▼
rusty build ──► layer index (.rusty/) ──► artifact cache (~/.rusty/cache/)
│
▼
binaries in .rusty/target/Command families
| Family | Role |
|---|---|
rusty env | Install and select Rust toolchains; which resolves active binaries |
rusty store | Low-level CAS: put/get/has blobs, trees, and crate tarballs |
rusty layers | Per-crate build layer index inside the current project |
rusty cache | Artifact groups keyed by source + toolchain + profile inputs |
rusty workspace | Monorepo discovery, affected analysis, version drift |
rusty init / migrate / lock / fetch | Project lifecycle |
rusty build / run / check / test | Compile and test (native driver or cargo passthrough) |
rusty test is always native. build, run, and check prefer the native driver for rusty.json workspaces when supported.
Cargo compatibility
rusty is not a thin wrapper. It reimplements critical paths in Zig and delegates to cargo only where the native driver does not yet cover a project shape.
During cargo-backed builds rusty still sets:
CARGO_HOME→ CAS-backed registry and git checkoutsCARGO_TARGET_DIR→<workspace>/.rusty/targetRUSTC_WRAPPER→rusty-wrapperfor transparent layer caching
That means even cargo passthrough benefits from the store and cache.