What are the thoughts of having a dedicated place in Cargo.toml to put other toolings configurations?
I'm mostly thinking about cargo subcommands, rustfmt, etc.
For example:
[package]
name = "test"
version = "0.1.0"
authors = ["Mathieu David <mathieudavid@mathieudavid.org>"]
[dependencies]
[tooling.rustmt]
something = "value"
This would reduce the number of tiny configuration files at the root and group everything together.
I've actually had this exact thought a few times, both for tools in the crate ecosystem (like rustfmt and clippy), and package-specific tools (like update-docs.py). It would be nice to head off the proliferation of config files, all with different naming styles and formats.
That said, I'm leaning toward only wanting it for things which are actually relevant for building the package as a dependency. For example, rustfmt configuration is just wasted bytes in the package cache. I feel like the rule of thumb is that if you don't need it for crates.io or building on a user's machine, it shouldn't go in Cargo.toml. Maybe have a standardised Tools.toml and encourage tools to use that in those cases?
I think the current way of dealing with this (e.g. clippy.toml, rustfmt.toml) is better than trying to pull it all together into one or two files.
Not only because you easily know where to look (the project has a clippy.toml? Then it probably uses clippy), but also because there's less room for mistakes (what if two tools like to use the same key?).
As more and more tools are being developed (cargo, clippy, rustfmt, clog-cli, ... ) the number of configuration files in your root folder becomes quite large.
I really like that we have small tools that do one specific task extremely well. I also like that a lot of those tools are highly configurable. It allows developers to pick the ones they need and tweak them for their projects. But a lot of small configurable tools means a lot of small configuration files, and that I like less.
That's not really a problem as every tool would use it's own name-space (table in TOML) for example if we would have one Tools.toml
[clippy]
a = "z"
b = "y"
c = "x"
[rustfmt]
a = "w"
b = "v"
c = "u"
...
Any clash in name-space could already happen currently if two tools share the same config file name.
I am not saying that this approach would be the holy-grail, but I think it would:
reduce the number of configuration files needed for tools in the rust ecosystem
create a standard way of exposing configuration options
encourage small tools to expose configuration options because they would not feel bad about introducing yet another configuration file for 2-3 configuration options.
Oh, and there's one thing I forgot to mention: If the file contains any error anywhere, the parser must do extra work to ensure the other parts at least get through (although I am pretty confident around toml). Also tools changing their config need to make sure they're not stepping on each other's toes. Multiple files don't have this problem.
Again, I don't see a problem with many small config files (and my experience in 20 years of software development is that those beasts tend to grow!), but if there is a demand, we can simply declare tools.toml or meta.toml (look! A nice bikeshed!) or whatever the config where every tool can put entries under its own crate name.
I have a pathological hatred of any package where the useful, "does work" code is smaller than the metadata. I also feel utterly ridiculous having a repository with more metadata files than source files. It's just silly. They clutter up my nice, meticulously organised directory tree. I mean, you end with with crap like .gitignore, .travis.yml, Cargo.toml, README.md and LICENSE: five files with different naming conventions and different formats and it's so untidy it just makes me want to chuck the whole lot out the window and scream at the *breathes into a paper bag*