{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif76abliqpfpfcgqb2gvq7ixisvwmaavk4wsfd4uc5oglicu3wb5i",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkp52336p6h2"
  },
  "path": "/t/pre-rfc-proposal-bound-cargos-implicit-upward-discovery-for-config-toml-files/24210#post_5",
  "publishedAt": "2026-04-30T06:45:05.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I appreciate the comments!\n\nUnfortunately, a config key would not solve the main use case for us. We build third-party repositories under a tool-managed environment, and we do not necessarily control or want to modify their `.cargo/config.toml`.\n\nIt also makes the boundary part of config discovery itself: Cargo would need to discover and load config files in order to know where config discovery should stop. That can maybe be designed as special side-band state, but for wrappers/tools we need the authoritative boundary to come from outside the discovered config graph.\n\nI think a repository-owned marker like `root = true` could still be useful for projects that want to declare their own boundary. It just seems complementary to, rather than a replacement for, an invocation/tool-controlled boundary.",
  "title": "[Pre-RFC] Proposal: bound Cargo's implicit upward discovery for config.toml files"
}