Allow local config files to override the default

[nrc]

We currently have a single toml file to provide config info. We should allow having a project-specific toml file which can override the defaults.

Easy-ish

[rkjnsn]

Would this involve removing support for a global configurations? It seams like it would be desirable to require customizations to be per-project and otherwise strictly follow the community style guidelines. I can see having per-installation settings leading to problems and inconsistencies.

[nrc]

I would like to have a default config file which is part of rustfmt and for parts of it to per overridden per-project by the local config files. I don't envisage more than one config file per-project. Or for a machine-local config to override a project-local or default config (other than for rustfmt tests and similar edge cases).

[jonhoo]

Ideally, rustfmt should also read the config from ~/.rustfmt, not from the directory in which it was compiled.

[nrc]

I don't think it should - the default config should be a default for all installs of rustfmt and should get updated when we change it, rather than being a per-user default. We might want a per-user config as well as the per-project and default configs. That should probably take precedence over per-project (I would strongly recommend against using such a thing, but I wouldn't object to having the ability to use it).

[jonhoo]

Oh, I agree there should be a global default, but rustfmt currently depends on the default config being in the current working directory, which is not ideal. For example, it means I cannot symlink the rustfmt binary into /usr/local/bin.

[nrc]

Oh, yeah, being in cwd is not ideal in that respect. I'm actually not sure where the best place is for it. I guess once we get into this, we need to get into having an install script or something (I'm not actually sure what the best practice is for files an executable requires - I've only worked on projects too small to care or too big for me to know about that kind of thing).

[sbstp]

I think that the tool should ship with a default/standard configuration file that can be overridden by other files. The override files can be defined at any level of the file system, allowing fine grained control of configurations. The lookup for override files starts at the working directory (or the directory containing the current file [dirname]) and goes up, stopping at the first file it finds.

For example, if I'm in /home/simon/projects/rust/, it will look for a .rustfmt in this order:

/home/simon/projects/rust/.rustfmt
/home/simon/projects/.rustfmt
/home/simon/.rustfmt
/home/.rustfmt
/.rustfmt

Users can group their project per configuration (for example, one configuration per organization/company, one configuration per user, etc.) Also, each project can have its own configuration file, and it won't be influenced by parent configurations since the lookup stops at the first one it finds (useful when working on someone else's project).

The fact that the standard configuration is loaded by default allows the users to change only a few details, without having to rewrite a full configuration file. I'd put the default/standard file in /usr/share/rustfmt on Linux, next to the binary on Windows, and no idea on Mac.

I can create a PR for this if it's a model that you like.

[nrc]

@sbstp I like the idea in principle, but I'd be keen to start simple and see what additional functionality is wanted. To start with I'd like to just have default and a per-project config files. Once that is working, then we could experiment with sub-directory or organisation or per-user configs too. For the latter, I don't think directories are the right model - I think we can't rely on people organising their projects like that - we could use some kind of includes in the config file or take config files as arguments or something.

As for where to put the config file, it sounds like we need some kind of install script in order to do this. I'm tempted to wait for cargo install for that, rather than rolling our own, but I don't want to block overridable configs on that.

If the starting simple approach is amenable, please do make a PR, it would be much appreciated!

[marcusklaas]

This works now!