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

Read configuration from environment variables #2398

Merged
merged 3 commits into from Feb 26, 2016

Conversation

Projects
None yet
5 participants
@alexcrichton
Copy link
Member

alexcrichton commented Feb 19, 2016

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

alexcrichton added some commits Feb 19, 2016

Refactor configuration return values
Wrap up the value/definition pair in a generic structure so we can extend it
well later.
Make Config::get private
Don't actually want to expose this, callers need to use the more concrete
methods anyway.
Read configuration from environment variables
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
@rust-highfive

This comment has been minimized.

Copy link

rust-highfive commented Feb 19, 2016

r? @wycats

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton

This comment has been minimized.

Copy link
Member Author

alexcrichton commented Feb 26, 2016

Got a chance to talk about this with @wycats today and we felt good about it. Right now this doesn't support reading lists or tables from environment variables, but that can always come later if we decide to invent an encoding scheme.

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned wycats Feb 26, 2016

@brson

This comment has been minimized.

Copy link
Contributor

brson commented Feb 26, 2016

How does this impact RUSTFLAGS? It would seem that Cargo wants the variable to be called CARGO_RUSTFLAGS. I think I don't mind either way, but doing it with CARGO_ fails to establish a non-cargo convention (and differs from how the rust build itself supports rustflags).

@brson

This comment has been minimized.

Copy link
Contributor

brson commented Feb 26, 2016

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 26, 2016

📌 Commit a40440c has been approved by brson

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 26, 2016

⌛️ Testing commit a40440c with merge 4a8a38c...

bors added a commit that referenced this pull request Feb 26, 2016

Auto merge of #2398 - alexcrichton:config-env-var, r=brson
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
@alexcrichton

This comment has been minimized.

Copy link
Member Author

alexcrichton commented Feb 26, 2016

Ah yeah I mentioned it in this comment. Basically I think it's fine that we would support RUSTFLAGS in addition to CARGO_BUILD_RUSTFLAGS.

The build.rustflags configuration is also a list of strings, which can't be read from environment variables with this PR, so it's still necessary that RUSTFLAGS exists in any case.

@bors

This comment has been minimized.

@bors bors merged commit a40440c into rust-lang:master Feb 26, 2016

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@alexcrichton alexcrichton deleted the alexcrichton:config-env-var branch Feb 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.