Tracking Issue for -Z configurable-env

[ehuss]

Summary

Original issue: #4121
Implementation: #9175
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#configurable-env

The -Z configurable-env option enables reading the [env] table from config which will set the specified environment variables.

Unresolved issues

• Interaction with environment variables cargo sets itself (some can be overridden, some cannot, for example anything set after fill_env like build-script env vars).

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[wickerwaka]

Is there a discussion about this occurring in some other other place?

[ehuss]

I don't think so. Feel free to discuss it here or on Zulip or internals. The boilerplate in the issue is just meant to keep the noise down so that people following the issue only get relevant updates, but I doubt there are too many people following here (esp since it was just opened).

[h4x3rotab]

This is still not available by setting cargo-features in Cargo.toml, but -Z configurable-env only. I'm wondering why it's not added.

[Eh2406]

It will have a -Z flag until it is stabilized. Do you think it should also have an opt in in Cargo.toml after sablazation?

[h4x3rotab]

Sorry, I misunderstood how cargo-features works. In my situation, I'd love to enable this unstable feature by Cargo.toml instead of command line flags, because in some cases (e.g. working with IDE or some other tools), there's no standard way to specify the unstable feature flag. However it turns out cargo-features is for the features affecting Cargo.toml file.

[Eh2406]

Does adding

[unstable]
configurable-env = true

to a .cargo/config.toml do what you need?

[oblique]

Any opinions on expanding an environment variable?

For example:

[env]
FOO = "$BAR/xyz"
PATH = "/opt/foobar/bin:$PATH"

[jonhoo]

Another consideration here is whether it should be possible to set the environment variables differently during build and execution. For example, it seems reasonable to allow using a different $PATH for cargo build and for the execution phase of cargo run or cargo test (if run has to build, then it would use the same env as cargo build for that part). In my case working within a larger build system, I'd like to have $PATH at execution time not contain commands provided by packages declared as "build time dependencies", and similarly to not have to make packages declared as "runtime-only dependencies" available just in order to call cargo build.