`.cargo/config.toml` env setting to pull value from terminal environment

tools and infrastructure cargo
1

Would be nice if there was a feature that allows you to pull the env value from the environment of the terminal that called the program.

For example, let's say I run this in the terminal:

export ENV1=VAL1
cargo t integration_test1

and let's say I have this in .cargo/config.toml:

[env]
ENV1 = { from_console = true }

Cargo should read from_console = true and consequently check what value ENV1 has in the environment of the terminal where I called cargo t integration_test1, and then use that value as if the config were like this:

[env]
ENV1 = "VAL1"

The use case I have in mind is to automatically log in to Docker with credentials that are automatically set via shell configuration file (such as ~/.config/fish/config.fish), so that I can automatically pull the image (from private repo), so I can run the integration test (for testing the communication between my program's image and the other private image) via testcontainers crate, without having to store the credentials inside the main repo.

Being able to do the above would allow me to automatically pull the required image if I don't already have it locally, so that people unfamiliar with my repo can easily run cargo t and have everything work without having to debug stuff and figuring out that there was an image that was supposed to be pulled, etc.

1 Like
2

Env vars are already inherited if you don't specify them in the [env] section.

3

Because Cargo already reads the external environment by default, the only reason I could think of to support this is to an env to default to override another layer in the config. Our general issue for resetting fields is AIlow to unset `.cargo/config` settings through a new `reset` config key · Issue #8687 · rust-lang/cargo · GitHub

4

This looks like it's meant to be a configuration option for the specific crate, but it's not using Cargo features.

I get that Cargo features are limiting due to lack of values, but env vars are problematic for a bunch of reasons: they're non-namespaced globals. They aren't explicitly associated with the crate(s) using them. They aren't defined in a standard discoverable place. They're global public state and get inherited by child processes if you don't clear them (especially for credentials it would be better to have something more targeted).

.cargo/config is for the user to define their environment, but not for the crates to define their interface. Ideally there should be some schema for the settings in Cargo.toml.

I think that for configuring behavior of crates or their tests it would be better to extend Cargo features to support values. Env vars going through Cargo defaults are a very indirect way of doing this.

1 Like