cargo-hakari stabilizes feature unification by generating a workspace-hack crate that every member depends on.
cargo rail unify achieves the same effect with explicit transitive pins in the workspace root or a selected member:
no generated crate to maintain, no extra dependency edge in every manifest, and the resolved graph remains
inspectable through normal Cargo manifests.
The goal is not to reproduce the workspace-hack topology in another format. Remove that topology, then let Cargo-Rail keep only the dependency and feature edges the resolved workspace requires.
- Create a branch and record the current
cargo treeoutput and build timing. - Remove workspace-hack dependencies, the hack crate's workspace member entry, and
hakari.toml. - Enable transitive pinning in
rail.toml. - Run
cargo rail unify --check --explainand review each planned pin. - Apply with
cargo rail unify --backup. - Run the workspace build and test suite, then compare
cargo tree --duplicateswith the baseline.
[unify]
transitive_pinning = { host = "root" }cargo rail init
cargo rail unify --check --explain
cargo rail unify --backup| cargo-hakari | Cargo-Rail |
|---|---|
| workspace-hack crate | no extra crate |
hakari.toml |
rail.toml |
cargo hakari generate |
cargo rail unify |
cargo rail unify undounify undo restores Cargo-Rail's latest manifest backup. Use version control to restore the removed workspace-hack files.