Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fine-grain control of Config.toml discovery #7887

Open
jsgf opened this issue Feb 15, 2020 · 0 comments
Open

Fine-grain control of Config.toml discovery #7887

jsgf opened this issue Feb 15, 2020 · 0 comments
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.

Comments

@jsgf
Copy link
Contributor

jsgf commented Feb 15, 2020

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.

@jsgf jsgf added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Feb 15, 2020
@ehuss ehuss added the A-configuration Area: cargo config files and env vars label Feb 25, 2020
jsgf added a commit to jsgf/cargo that referenced this issue May 20, 2020
This implements the CARGO_CONFIG_PATH environment variable, which defines
in which order `cargo` searches for config files. This overrides the
default "search parent directories" order.

Fixes rust-lang#7887
@epage epage added the S-needs-team-input Status: Needs input from team on whether/how to proceed. label Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants