{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihck3qmxtgppfnrdksbhvzybl6si7hrwp6cispmh3j537lrnxgbou",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3merx6ejvpmw2"
  },
  "path": "/t/what-prevents-cargo-from-adding-bench-bin-example-dependencies/24004#post_9",
  "publishedAt": "2026-02-14T00:51:16.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "One thing that bugs me is that a single package (one `Cargo.toml` file) with multiple crates (AKA targets, products, bins/benches/examples) looks roughly similar to having a single workspace with multiple packages. It's like two zoom levels of the same fractal.\n\nThere's pressure to add more separation between crates of a package, as well as pressure to add more integration between packages in a workspace.\n\nIf we extrapolate these trajectories, Cargo will end up with two almost equal ways of making multi-crate workspaces, but with historical small differences between them that are going to cause confusion and debates which one is the right one.\n\nSo I'm wondering whether these two can actually be made the same thing, in a direct way. What if workspaces could be freely nested? What if lib+bin packages were retroactively explained to be workspaces containing a lib-only package and a bin-only package, merely defined using \"syntax sugar\" of `[lib]` and `[[bin]]` in one file instead of separate `Cargo.toml` files for each.\n\nImagine that you could start with a lib+bin `Cargo.toml` package, but once you needed to have separate dependencies for the bin, you would make a full `cli/Cargo.toml` for the binary with its unique dependencies and features, but some yet-to-be-invented inclusion/inlining mechanism would let you merge it back with its lib crate to keep it behaving just like before, like single lib+bin package.",
  "title": "What prevents Cargo from adding `[bench/bin/example-dependencies]`?"
}