{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicdeoxi3tgo4zwr776sxaxrlwxtr4kg7mp2lasi5h6qapge3bbvle",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mh3dr35u7nq2"
  },
  "path": "/t/cargo-project-config-unification/24082#post_5",
  "publishedAt": "2026-03-14T23:37:54.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "↩︎"
  ],
  "textContent": "I understand you to be saying that there are a bunch of existing `.cargo/config.toml` parameters that are problematic to set in the context of a workspace or package, and you (the Cargo team) don't want to be seen as endorsing their use in that context, by making them usable from `Cargo.toml`. Is that an accurate summary of what you're trying to communicate?\n\nAssuming so, first, let me explain in somewhat more detail where I'm coming from. What I care about is getting to a place where no project ever _needs_ to ship a `.cargo/config.toml` in their source tree, as expeditiously as possible. Right now, sometimes people have to do that; for example, I know of software that _has_ to be built with `-C target-feature=+crt-static -C relocation-model=static` or it won't link. The only way to accomplish that, as of the last time the project I'm thinking of was updated,[1] was to set `rustflags` in `.cargo/config.toml`.\n\nBut it's _bad_ that people have to do that, and I hope you agree with that at least in principle. Many developers don't even know you _can_ put a `.cargo/config.toml` in a workspace or package, and so it's a potential source of confusion for people new to a project. It might even be a place where someone could hide underhanded tricks, in the style of the `xz` exploit. Both these issues are made worse by `.cargo/config.toml` being a hidden file.\n\nFurthermore, it seems to me that any setting that would be problematic in a `Cargo.toml` is equally problematic in a workspace or package `.cargo/config.toml`, only, because it's much less visible in `.cargo/config.toml`, the problems are exacerbated. That's why I can't get behind your plan to sort out the problems and _then_ only move the settings that aren't problematic. I think a world in which all those problematic settings _can_ appear in `Cargo.toml`, but Cargo throws deprecation warnings on the mere existence of package- or workspace-scope `.cargo/config.toml`, is strictly better than the world we have now. I also think that doing the file-level deprecation _first_ and then going back to the problematic settings case by case is a better overall strategy for getting the whole job done in a reasonable amount of time.\n\n* * *\n\n  1. it's been on ice for a bit more than a year, so the situation may well have changed ↩︎\n\n\n",
  "title": "Cargo project config unification"
}