{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifrd4uv2iduyeaezt4frusyu6ynek2gttfxpw3qfmnvmeu2ilwnfi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkra53rufr42"
  },
  "path": "/t/pre-rfc-proposal-bound-cargos-implicit-upward-discovery-for-config-toml-files/24210#post_9",
  "publishedAt": "2026-05-01T03:24:34.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "reserves the room for templating paths"
  ],
  "textContent": "I shouldn't skip talking about use cases first, though when I was stabilizing `config-include` I actually came up with a maybe-simpler implementation idea. Let me just dump it here.\n\nWe can add a top-level `config-discovery=true|false` key in Cargo configuration. As a native Cargo config field, it automatically supports TOML config, env `CARGO_CONFIG_DISCOVERY`, and CLI `--config config-discovery`. You can just run `env CARGO_CONFIG_DISCOVERY=false cargo build` to stop loading any config, as env wins over file discovery.\n\nAlso during the stabilization, we reserves the room for templating paths in `include`, so potentially we can implement things like\n\n\n    config-discovery = false\n    [[include]]\n    path = \"{workspace-root}/.cargo/config.toml\"\n    [[include]]\n    path = \"{cargo-config-home}/config.toml\"\n\n\nto read only config from CARGO_HOME and your workspace root.\n\nWhile search ceiling looks nice and convenience, I personally think whoever depended on a fragile auto-discovery was just because config-include wasn't stabilized. They should migrate to `include` if not yet.",
  "title": "[Pre-RFC] Proposal: bound Cargo's implicit upward discovery for config.toml files"
}