Integrating configuration into Cargo.toml

[Nemo157]

Recently I was getting annoyed at how many metadata files are in the root of my workspace. To combat this issue it feels like tooling that is completely cargo-focused like this should really be storing its configuration in the Cargo.toml. The example from the readme could look like:

[workspace.metadata.lints]
warn = [
  "clippy::empty_structs_with_brackets",
  "clippy::cast_possible_truncation",
]

This could also support some of the usecases from #3 easily. The lints could be merged from workspace.metadata.lints and package.metadata.lints to support crate-specific overrides.

[ericseppanen]

Good point, it never occurred to me to put the configuration in Cargo.toml.

Do guidelines exist for how third-party tools should organize their configuration data? Should a tool called cargo-cranky keep its config data under package.metadata.cranky?

[jayvdb]

nightly now supports a top level lints in Cargo.toml, c.f. rust-lang/cargo#12115

The usefulness of cargo-cranky will steeply diminish soon, unless cranky decides to add more features not found in nightly.

Do guidelines exist for how third-party tools should organize their configuration data? Should a tool called cargo-cranky keep its config data under package.metadata.cranky?

IMO package.metadata.cranky would be better, but package.metadata.lints also makes sense, and it isnt going to have clashes any time soon because most people will be using the new nightly lints table soon.

[Nemo157]

Not just nightly, 1.74 which is going to beta in a week has that feature stabilized.

[ericseppanen]

That's great news! I'll update the README when 1.74 comes out.