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

Tracking Issue for -Z configurable-env #9539

Closed
1 task
ehuss opened this issue Jun 3, 2021 · 11 comments
Closed
1 task

Tracking Issue for -Z configurable-env #9539

ehuss opened this issue Jun 3, 2021 · 11 comments
Labels
A-environment-variables Area: environment variables C-tracking-issue Category: A tracking issue for something unstable.

Comments

@ehuss
Copy link
Contributor

ehuss commented Jun 3, 2021

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.

@ehuss ehuss added A-environment-variables Area: environment variables C-tracking-issue Category: A tracking issue for something unstable. labels Jun 3, 2021
@wickerwaka
Copy link
Contributor

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

@ehuss
Copy link
Contributor Author

ehuss commented Jun 4, 2021

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
Copy link

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
Copy link
Contributor

Eh2406 commented Jun 12, 2021

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
Copy link

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
Copy link
Contributor

Eh2406 commented Jun 12, 2021

Does adding

[unstable]
configurable-env = true

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

bors added a commit that referenced this issue Jun 21, 2021
Don't allow config env to modify vars set by cargo

This changes how the `[env]` variables are applied. They will no longer replace any variables that are being set by cargo itself, whether or not the `force` flag is set. The `force` flag still determines whether existing variables from the environment can be overridden or not.

Addresses unresolved issue in #9539
@oblique
Copy link

oblique commented Oct 5, 2021

Any opinions on expanding an environment variable?

For example:

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

@jonhoo
Copy link
Contributor

jonhoo commented Oct 20, 2021

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.

@jonhoo
Copy link
Contributor

jonhoo commented Oct 29, 2021

This should presumably be closed since this feature was stabilized in Rust 1.56?

I guess there was never an answer to the unresolved question around interaction with envvars that Cargo sets itself?

@jonhoo
Copy link
Contributor

jonhoo commented Oct 29, 2021

I'd also like to propose another (minor?) missing part of the current design: the ability to unset an environment variable. The current design would only let you set a variables value to "", but that's not quite the same.

@ehuss
Copy link
Contributor Author

ehuss commented Oct 31, 2021

Yea, thanks for the ping. Going ahead and closing since this was stabilized in #9411.

If you want to extend it to support unsetting, that is probably OK. I can imagine an {unset=true} flag or something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-environment-variables Area: environment variables C-tracking-issue Category: A tracking issue for something unstable.
Projects
Status: Done
Development

No branches or pull requests

6 participants