Support multiple cargo configuration files in .cargo

[jonhoo]

Describe the problem you are trying to solve
I want to check in some subset of my cargo configuration into version control (e.g., aliases useful to all devs), but not others (e.g., parts that hold custom patches, rustflags, or other local build options).

Describe the solution you'd like
I would like to be able to split my configuration file into multiple files, and then only check in some of them.

Notes
Currently, my options are:

• Check in the entire cargo configuration into version control, and thus impose my local build configuration on other devs.
• Don't check in the cargo configuration and find an out-of-band mechanism for distributing common project configuration.
• Nest my project in an extra subdirectory and place the local configuration in a parent directory and the shared configuration in the project directory itself.

None of these are ideal. It'd be nice if cargo supported something like a .cargo/config.toml.d/ directory that could then contain any number of configuration files that are merged.

[Revantus]

Hi @jonhoo, does splitting your config into $HOME/.cargo/config.toml for personal configurations and /projects/foo/.cargo/config.toml for project specific, shared configurations not work in this case?
Cargo Doc Reference

[jonhoo]

No, unfortunately not. It's not uncommon to have personal per-project configuration options (like sharing a target directory across related packages or sharing a rustflags definition).

[Revantus]

I can take a look at implementing this. Using the method in system.conf.d for priority loading based on reverse lexicographical sort. So that 99-personal.toml would overwrite 00-shared.toml. First pass implementation would be the single directory config storage and ignore folders inside the config.toml.d.

[ensc]

perhaps something like an include statement could be implemented. So, .cargo/config.toml could look like

[files]
include = "conf.d/*.toml"
include = "required.toml"
include = "-local.toml"
include = "-local-%h.toml"

When wildcards expand to null or when prefixed by -, files are optional (can be missing). Else, they are required.

The optional local.toml file above can contain e.g. local setup (like build.target-dir) and can be excluded e.g. in .gitignore.

Perhaps some placeholders can be implemented too:

• %h local hostname
• %u username
• %H hash of full path to Cargo.toml (--> allows project specific configuration e.g. in $HOME/.cargo/project-49a7abbdc564bf92a27c31a936047cda.toml)

This allows to share the source on NFS and set environment specifics configurations (e.g. paths)

[jonhoo]

There is already an unstable include feature that could maybe be extended that way: #7723

[Revantus]

That's what I was thinking as well. With the cli taking priority for load order.