Fine-grain control of Config.toml discovery #7887
Labels
A-configuration
Area: cargo config files and env vars
C-feature-request
Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
S-needs-team-input
Status: Needs input from team on whether/how to proceed.
Describe the problem you are trying to solve
Cargo's documented algorithm for configurations is hard to control - it searches in many places reading every config file it can find, and ultimately combines them into a single effective config.
This means that its very hard to limit where it finds config files - for example, if any parent directory happens to have a
.cargo/config.toml
it will be incorporated, even if its unrelated to the current use-case. The only way to limit it is to set CARGO_HOME and set its current working directory to somewhere where there's sure to be no.cargo/config.toml
files in parent directories (ie, ideally near the root directory).As an example of a potential hazard, if one were trying to do an isolated build in
/tmp/mybuild-XXXX
(ie, a standard randomized temp directory), someone could impinge on that build by creating/tmp/.cargo/config.toml
- including overriding dependencies or having other critical effects on the build's integrity.Currently the only sure-fire way to guarantee isolation is by using a container or some other isolation mechanism. That's excessively heavy-weight.
Describe the solution you'd like
Define a
CARGO_CONFIG_PATH
environment variable, which is structured like a typical path environment variable: a string containing colon-separated pathnames in which to search for configurations. If set, it would absolutely control all places searched for configuration files - it wouldn't even look in the current directory unless.
is specified as a path element.The path elements are directories in which it searches for
.cargo/config.toml
, analogous to the existing search algorithm.If
CARGO_CONFIG_PATH
is not set, then the normal config search algorithm is used.This would not affect configuration from environment variables. The assumption is that they're easier to control (and since this mechanism requires an environment variable, it already relies on them being controlled).
When merging configurations, the precedence is defined by order within the path, with earlier in the path having higher precedence.
The text was updated successfully, but these errors were encountered: