Add a --ignore-local-config
flag for ignoring local .cargo/config.toml
files
#8643
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-triage
Status: This issue is waiting on initial triage.
Describe the problem you are trying to solve
Cargo configuration files (
.cargo/config
or.cargo/config.toml
) provide powerful options for changing how a project is compiled. Since they are based on file system hierarchy and the current working directory wherecargo
is invoked, they automatically apply to all subdirectories. This property is useful in many situations, e.g. when running thecargo
command from thesrc
folder of a project, but it can lead to problems in some other cases.One potential source of problems is the
--manifest-path
argument ofcargo
. This argument allows to run acargo
command on a crate in a different directory. Since the current working directory is not changed for this, the configuration of the folder where thecargo
command is run from is applied, not the config from the referenced project. This might break the compilation, e.g. when a default target or special rustflags are set in a local config file.A second source of problems are programs that invoke
cargo
commands, for example somecargo
related command line applications. Depending on the directory they are run in, they might behave completely differently because all project-local configuration is applied. This was also a problem for thecargo install
subcommand, until the behavior was changed to only load~/cargo/.config
forcargo install
.Describe the solution you'd like
To solve the mentioned problems, an
--ignore-local-config
flag forcargo
would be very useful. Similar to the behavior ofcargo install
,cargo
invocations with this flag would only load the global configuration from~/cargo/.config
, but not any other local configuration files from the current working directory. This way, cargo commands can be made independent of the current working directory if desired.Notes
I'm happy to create a pull request for this, but I wanted to ask for opinions first. I think the
Config::reload_rooted_at
method would make the implementation quite simple. Of course we could add such a flag as an unstable flag first.The text was updated successfully, but these errors were encountered: