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.

Sign up for GitHub

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

Jump to bottom

Finish implementing cargo config and related support #2362

Closed
alexcrichton opened this issue Feb 6, 2016 · 3 comments · Fixed by #9302
Closed

Finish implementing cargo config and related support #2362

alexcrichton opened this issue Feb 6, 2016 · 3 comments · Fixed by #9302
Labels
A-configuration Area: cargo config files and env vars A-new-subcommand Area: new subcommand A-tooling Area: interaction with other tools

Comments

@alexcrichton
Copy link
Member

Configuration in Cargo initially had a relatively grand vision, but much of it was unfortunately never implemented. This issue should help track finishing this support as well as explaining what it is intended to be!

A cargo config subcommand

It was initially intended to have a cargo config subcommand ala git config or bundle config. Configuration values could be read/written through this interface to the various locations on the system as need be.

An example of this would be Bundler's bundle config command.

The major blocker for this is being able to read a TOML file, modify some aspects of it, and then write it back to the filesystem. This should crucially preserve aspects such as comments, formatting, etc. Today we cannot do this.

Environment variables for configuration

Right now we've got a smattering of environment variables, but it's somewhat inconsistent in terms of what's an environment variables, what's a command line option, and what's a configuration option.

I believe it was originally intended that environment variables and configuration options should be one-and-the-same. All configuration options should have a mapping to an environment variable which provides the ability to read/write that field. For example Bundler has this as well.
@alexcrichton alexcrichton added A-new-subcommand Area: new subcommand A-tooling Area: interaction with other tools labels Feb 6, 2016
alexcrichton added a commit to alexcrichton/cargo that referenced this issue Feb 19, 2016
@alexcrichton
Read configuration from environment variables
a40440c 
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
@alexcrichton alexcrichton mentioned this issue Feb 19, 2016
Merged
bors added a commit that referenced this issue Feb 26, 2016
@bors
Auto merge of #2398 - alexcrichton:config-env-var, r=brson
4a8a38c 
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
@dwijnand
Copy link
Member

So looks like this is blocked on the switch to toml_edit.

@ehuss ehuss added the A-configuration Area: cargo config files and env vars label Sep 21, 2019
@ehuss ehuss mentioned this issue Sep 21, 2019
Open
@ehuss
Copy link
Contributor

ehuss commented Feb 4, 2021

I have put together a proposal for the design of cargo config here: https://hackmd.io/@ehuss/rkjp32Fg_

@rust-lang/cargo FYI, if you have a chance to read and maybe give feedback.

@alexcrichton
Copy link
Member Author

Thanks for typing this up @ehuss!

My initial reaction was that I was wondering if we could do something git-like where cargo config the-key would work for fetching and (in the future) cargo config the-key the-value would work for setting. After reading over the references at the end of your notes, though, I see that it's also quite common nowadays to use subcommands. Given that and how adding cargo config the-key would be backwards-compatible I think it's fine to use the subcommands for now.

Otherwise I thought your specification looked great. I like the multiple output options which should be easy enough for us to implement and should help make it a relatively powerful tool even right-out-the-gate.

The other thought I had reading it was towards the end about alternative ways of configuring things, e.g. RUSTC vs build.rustc. I would personally think that we should reimplement Cargo internally to not have these special one-off environment variables but instead have them built-in to Config loading. For example RUSTC, CARGO_BUILD_RUSTC, build.rustc would be the order of precedence for checking what rustc to use. (similarly for other keys where possible). I'm not sure that this would fit 100% cleanly into our configuration with no breakage, but I think it'd be great to move in that direction at least.

This was referenced Mar 25, 2021
Open
Merged
@bors bors closed this as completed in 7204d39 Mar 30, 2021
@avrong avrong mentioned this issue Feb 1, 2022
Merged
bors bot added a commit to intellij-rust/intellij-rust that referenced this issue Apr 29, 2022
@bors @vlad20012
Merge #8494
6ab14f3 
8494: CARGO: Retrieve config information r=vlad20012 a=avrong

Adds the ability to get config properties using `cargo config get` subcommand tracked in rust-lang/cargo#2362. It can be improved in the future as rust-lang/cargo#9301 features will be implemented.

Currently, it retrieves the config values of a specified path and parses them into a tree. Methods like `getBuildTarget` and `getEnvParams` return specific structured data

Co-authored-by: vlad20012 <beskvlad@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-configuration Area: cargo config files and env vars A-new-subcommand Area: new subcommand A-tooling Area: interaction with other tools
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add cargo config subcommand. ehuss/cargo
3 participants
@ehuss @alexcrichton @dwijnand