Read configuration from environment variables#2398
Conversation
Wrap up the value/definition pair in a generic structure so we can extend it well later.
Don't actually want to expose this, callers need to use the more concrete methods anyway.
This commit adds a more principled system to rationalize what ends up being a configuration value versus an environment variable. This problem is solved by just saying that they're one and the same! Similar to Bundler, this commit supports overriding the `foo.bar` configuration value with the `CARGO_FOO_BAR` environment variable. Currently this is used as part of the `get_string` and `get_i64` methods on `Config`. This means, for example, that the following environment variables can now be used to configure Cargo: * CARGO_BUILD_JOBS * CARGO_HTTP_TIMEOUT * CARGO_HTTP_PROXY Currently it's not supported to encode a list in an environment variable, so for example `CARGO_PATHS` would not be read when reading the global `paths` configuration value. cc rust-lang#2362 cc rust-lang#2395 -- intended to close this in tandem with rust-lang#2397
|
r? @wycats (rust_highfive has picked a reviewer for you, use r? to override) |
|
How does this impact |
|
@bors r+ |
|
📌 Commit a40440c has been approved by |
This commit adds a more principled system to rationalize what ends up being a configuration value versus an environment variable. This problem is solved by just saying that they're one and the same! Similar to Bundler, this commit supports overriding the `foo.bar` configuration value with the `CARGO_FOO_BAR` environment variable. Currently this is used as part of the `get_string` and `get_i64` methods on `Config`. This means, for example, that the following environment variables can now be used to configure Cargo: * CARGO_BUILD_JOBS * CARGO_HTTP_TIMEOUT * CARGO_HTTP_PROXY Currently it's not supported to encode a list in an environment variable, so for example `CARGO_PATHS` would not be read when reading the global `paths` configuration value. cc #2362 cc #2395 -- intended to close this in tandem with #2397
|
Ah yeah I mentioned it in this comment. Basically I think it's fine that we would support The |
|
☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
5 participants
This commit adds a more principled system to rationalize what ends up being a
configuration value versus an environment variable. This problem is solved by
just saying that they're one and the same! Similar to Bundler, this commit
supports overriding the
foo.barconfiguration value with theCARGO_FOO_BARenvironment variable.
Currently this is used as part of the
get_stringandget_i64methods onConfig. This means, for example, that the following environment variables cannow be used to configure Cargo:
Currently it's not supported to encode a list in an environment variable, so for
example
CARGO_PATHSwould not be read when reading the globalpathsconfiguration value.
cc #2362
cc #2395 -- intended to close this in tandem with #2397