Cargo project config unification

tools and infrastructure cargo
1

Where are we at on merging .cargo/config.toml into Cargo.toml?

Optional features are part of the crate — the project should say so
2

We will likely never directly support .cargo/config.toml fields in Cargo.toml. Instead, we will need to look at how they should be abstracted in Cargo.toml. This is being tracked in Tracking Issue: Support project-specific config in manifest · Issue #12738 · rust-lang/cargo · GitHub.

3

This plan means package/workspace .cargo/config.toml will continue to need to exist indefinitely. I don't like that.

What would be so bad about moving everything, and I really do mean everything, from .cargo/config.toml to Cargo.toml, right now, so that we can deprecate the existence of .cargo/config.toml in packages and workspaces as soon as possible?

You could still migrate these settings to a better schema within Cargo.toml, later, probably on a setting-by-setting basis. It seems to me it would go more smoothly overall.

4

I'd recommend actually looking at the config before making such broad statements

  • alias: there is no manifest lookup for these today
  • build: half of these are caller, machine, or user specific
  • credential-alias: user specific
  • doc: user or machine specific
  • env: unenumerable use case
  • future-incompat-report: user specific
  • cache: user or machine specific
  • cargo-new: user as the point is that you aren't in a repo
  • http: user or machine specific
  • install: caller, user, or machine specific
  • net: ditto
  • patch: already in manifest
  • profile: ditto
  • resolver: controlled by workspace.resolver. Maybe more can go in but design work is needed
  • registries: unsure
  • source: ditto
  • target links: overriding build scripts should likely not be in a static file
  • term: caller, user, or machine specific

Another problem is RUSTFLAGS is a raw escape hatch that users can shoot themselves in the foot with and so it needs a "here be dragons" rather than having a paved path in the manifest,

3 Likes
5

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 ↩︎

5 Likes