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

Add a --ignore-local-config flag for ignoring local .cargo/config.toml files #8643

Open
phil-opp opened this issue Aug 23, 2020 · 3 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-triage Status: This issue is waiting on initial triage.

Comments

@phil-opp
Copy link
Contributor

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 where cargo is invoked, they automatically apply to all subdirectories. This property is useful in many situations, e.g. when running the cargo command from the src folder of a project, but it can lead to problems in some other cases.

One potential source of problems is the --manifest-path argument of cargo. This argument allows to run a cargo command on a crate in a different directory. Since the current working directory is not changed for this, the configuration of the folder where the cargo 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 some cargo 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 the cargo install subcommand, until the behavior was changed to only load ~/cargo/.config for cargo install.

Describe the solution you'd like

To solve the mentioned problems, an --ignore-local-config flag for cargo would be very useful. Similar to the behavior of cargo 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.

@phil-opp phil-opp added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Aug 23, 2020
@ehuss ehuss added the A-configuration Area: cargo config files and env vars label Sep 18, 2020
@steveklabnik
Copy link
Member

I also would find this useful, I think. My situation is thus: I have a "build just this package" build, and a "build this package as part of a bigger project" build. For the former, setting some linker arguments in .cargo/config is great, but then for the second build, I don't want those settings, but different ones.

@jgouly
Copy link

jgouly commented Dec 10, 2020

I used to use --manifest-path since it allowed to mount my code as read-only in a VM, while building from a writable directory.
However the fact that .cargo/config.toml isn't respected means I can't do that anymore. A flag like --use-config=<path> or something might be useful in this case (or a flag to pick the config from the root of the project, even if it's not the current directory)

@phil-opp
Copy link
Contributor Author

@jgouly Check out https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336. The proposal takes a different way than your suggestion, but I think it should help in your use case as well. The good news is that the Cargo team has signaled their approval of this proposal, so we just need to implement it.

@epage epage added the S-triage Status: This issue is waiting on initial triage. label Nov 20, 2024
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-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants