feat: stop discovering config.toml beyond CARGO_CONFIG_STOP_SEARCH_PATH

[wolfv]

What does this PR try to resolve?

We are using cargo / Rust in Pixi. Pixi (by default) doesn't do totally proper sandboxing, and it is also somewhat unsolved how to do proper sandboxing on Windows. However, we do create local environments & Rust installations. When building Rust software, our users sometimes have the problem that they work in a folder under their $HOME directory, and sometimes one of the parent directories contain a config.toml file.

We already set the $CARGO_HOME directory to something non-global. However, it would be nice if we can prevent cargo from walking "upwards" to find the parent config.toml files for better sandboxing (although it's obviously not a real sandbox).

For this reason, I've tried t implement a new environment variable: CARGO_CONFIG_STOP_SEARCH_PATH. With this env var set, cargo should only traverse "up to" the CARGO_CONFIG_STOP_SEARCH_PATH in search of additional config.toml files.

It would help us quite a bit if this was added to Cargo, as our only workaround right now is to warn the user.

How to test and review this PR?

(TODO)

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ehuss, @epage, @weihanglo
• @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
• Random selection from ehuss, epage, weihanglo

[epage]

While I understand the importance of this feature and the work you put into it, we've found that posting a PR is not a helpful way of moving design discussions forward. Instead, the thing to do is to work to drive the design discussions forward in one of the relevant threads

• Cargo config search meta issue. #9769
• Fine-grain control of Config.toml discovery #7887
• Add flag to ignore all parent directory configs #7621
• Add a --ignore-local-config flag for ignoring local .cargo/config.toml files #8643

We have the general recommendation documented in our contrib docs. I've gone into more detail at https://epage.github.io/dev/pr-style/#d-issue and have suggestions on how to move threads forward like the ones above at https://epage.github.io/dev/pr-style/#d-summarize.

To shift the focus to the issues and to take this out of our review queue, I'm going to go ahead and close this. That is not a statement on this particular design, your work, or you. Maybe once the design is resolved, this very PR will be re-opened to look over the implementation.

[wolfv]

Hi @epage thank you for getting back to me. I totally understand your position, but it's not very encouraging to see how long they have been open, and unresolved.

Is there no way to have a simple solution through some env var (for me, a hidden one is fine as well), as there is absolutely no workaround for us.

In any case, I am also happy to engage in the discussions and see if we can move forward, somehow.

[epage]

They have been opened because no one is driving the effort. That is the biggest thing holding features back.

As for a short term solution, the problem is Cargo's compatibility requirements means we art stuck with it. We have to make sure different features work well together. In particular, there is risk for "out of sight, out of mind" features accidentally being broken by other features. We can have unstable features but it is generally best if those are being driven towards stabilization rather than having a large unstable backlog.

[wolfv]

Started this thread here: https://internals.rust-lang.org/t/pre-rfc-proposal-bound-cargos-implicit-upward-discovery-for-config-toml-files/24210

Does that look like a good place to start? I am willing to see this through to the end - I also don't personally care a lot about the shape of the solution but I am sad that we cannot override / configure this and it really breaks our users workflows for no good reason :)

And also, thank you @epage for being a Rust hero! We love your work :)

[epage]

As I said, the first step before making a proposal is collecting the information to have the context for evaluating a proposal. I'd recommend reading over https://epage.github.io/dev/pr-style/#d-summarize and looking at the examples, like #9930 (comment)