Is it possible to standardize additional config file naming?

tools and infrastructure cargo
1

My projects often have:

├── .cargo/
│      └── config.toml
├── Cargo.toml
├── src/
├── rustfmt.toml
└── rust-toolchain.toml

Having files of different names scheme (ex: rustfmt.toml not rust-fmt.toml like rust-toolchain.toml) and in different locations is a bit messy in my opinion.

Could this be standardized to something like:

 ├── .rust/
 │      ├── fmt.toml
 │      ├── toolchain.toml
 │      └── cargo-config.toml
 ├── src/
 └── Cargo.toml

Is this even possible to standardize since these things are read by different tools (Cargo, rustfmt, rustup, Clippy, etc.) ?

In Tool configs in Cargo.toml (e.g. rustfmt, clippy) and alternatives brainstorming this issue was mentioned:

Reading this thread it seems lots of people are interested in cleaning this up, in this case before the thread died they brought up using package.metadata, however, I wonder if just standardizing the pathing would be better than changing how the files themselves are consumed.

Thanks for reading and hopefully this isn't something already being worked on or closed out as out-of-scope.

2

It would be awesome if each of those tools had the option to receive their config through package.metadata in Cargo.toml. That way, you would be able to have just one config file if you wished to, but not break backwards compatibility if people prefer to stick with separate files.

That is, for example, for cargo, currently there's a stack of config files that first reads .cargo/config.toml, then if it's not present read ~/.cargo/config.toml. With this option, the stack would be: forst read [package.metadata.cargo] in Cargo.toml, then read .cargo/config.toml, then read ~/.cargo/config.toml. Ditto for all other Rust tools that litter the project directory with their own config files.

3 Likes
3

Keep in mind that rustfmt.toml is a configuration file for rustfmt so that name makes sense.

.rust/

Some people are pushing for development tools to standardize on using a .config/, see GitHub - pi0/config-dir: 📁 A proposal for the .config/ directory.. While I've expressed some concern over it (Alternative Directory Names · pi0/config-dir · Discussion #3 · GitHub), I'm guessing there would be a bigger drive to support something like that than a new rust-specific directory.

There are two problems with this:

  • Some of those tools are cargo agnostic and there is generally a hard line that they can only specialize diagnostics for cargo and not do deeper integration.
  • Some of these configuration files are environmental configuration (read based on current-dir), not package or workspace configuration, and reading from Cargo.toml would imply the latter, confusing things.

Alternatively for .cargo/config.toml, we have Tracking Issue: Support project-specific config in manifest · Issue #12738 · rust-lang/cargo · GitHub for finding how to abstract project-specific parts of .cargo/config.toml into Cargo.toml.

4

Is the idea here to have separate Cargo config for each crate (or each binary crate) in a workspace?

5

As I said, the goal of that issue is to find ways to specify things in Cargo.toml, so no Cargo Config would be involved. Whether we migrate things to being at the workspace level, package level, or crate level depends on what we are migrating. We have to handle each on a case-by-case basis.

1 Like