Want env var specifying overriding config file

[ijackson]

Problem

I have a situation where I have a .cargo/config which is nearly always right, and which I definitely very firmly want to be the default, but I need to be able to occasionally override it.

Because cargo simply searches up the directory tree there is no easy way to do this right now. I could override the config settings using env vars, but since some of the settings are tables that is no good.

Proposed solution

There should be an environment variable CARGO_CONFIG_INCLUDE which contains a :-separated list of TOML files. These should be read after all the .cargo/config files but processed before the command line, so that it overrides config files but is in turn overridden by the command line.

On Windows the list should be split (only) on ;. For the benefit of Windows, to make it possible to be compatible with both Unix and Windows, on Unix the list should be split on ; as well as :. As a result on Unix : and ; in filenames would be inexpressible; likewise ; in filenames on Windows. This is the traditional approach to path-like variables.

[ijackson]

This is related to #6699 "Proposal: Command-line config"

[ehuss]

This is almost identical to what #6699 proposes, although it uses toml syntax. Would the toml syntax be particularly difficult to use?

[zachlute]

@ijackson Was just randomly looking through issues and noticed #6699, which accomplishes this same thing in a different manner, was closed. Is that enough for your needs, or do you still need an environment variable solution for some reason? It'd be nice to close this out if that solution meets your needs!

[epage]

Cargo commands accept --config <path>. Is that sufficient for this use case?

[weihanglo]

I'm going to close due to inactivity. --config <config-path> should be able to cover most of the use cases in this proposal. Let us know if there is something overlooked.

[kaspar030]

--config <config-path> should be able to cover most of the use cases in this proposal. Let us know if there is something overlooked.

One huge downside of --config <path> is that it is not transitive, e.g., cargo-metadata when called in a build.rs is not aware of the extra configuration file. That is actually the case for most cli supplied configuration settings, and it (more or less subtly) breaks builds.

One example would be --config 'patch.crates-io.foo.path=... or --config <path> supplied patch.crates-io...=..., which just won't show in build.rs invoked cargo metadata output.

[patch.foo] fields also cannot be set via environment. I'm not aware of any way of supplying "global" cargo configuration options like that other than within files that are collected through the usual search path.

I really miss CARGO_INCLUDE=<path> here. Or full CARGO_PATCH_... support.

The usual file includes don't work for us, we're wrapping Cargo to support a large build matrix, similar to how Tock is doing it. Having only one configuration "active" at one time is quite limiting.