Cargo project config unification

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?

Assuming 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.

But 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.

Furthermore, 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.

1. it's been on ice for a bit more than a year, so the situation may well have changed ↩︎