Tracking: `settings.toml` and its stability guarantees

[rami3l]

I am bringing this up because of @djc's point that introducing too many environment variables for configuration might be too noisy: #4869 (comment)

It seems that, following cargo's convention, a lot of cargo's config should have env var counterparts. Should rustup move more or less towards that direction?

Also there has been a previous topic regarding Nix-generated settings.toml in #4167, the question is whether we should stabilize at least a part of this config.

For now I have this on my machine:

version = "12"
default_toolchain = "stable-aarch64-apple-darwin"
profile = "default"
auto_install = "disable"

[overrides]

... but it's not entirely clear if this config should change much (and thus can be backed up/generated by a dotfile manager like chezmoi/Nix) and if so under what circumstances. Using rustup default to change the settings might look surprising because one may expect that only rustup set can change it.

Now that we have state.toml maybe we can move some values over there.

[djc]

It seems that, following cargo's convention, a lot of cargo's config should have env var counterparts. Should rustup move more or less towards that direction?

Can you be more concrete about what you mean with this?

Also there has been a previous topic regarding Nix-generated settings.toml in #4167, the question is whether we should stabilize at least a part of this config.

I'd be okay with documenting the contents of config.toml, noting the caveat that newer versions would change things.

... but it's not entirely clear if this config should change much (and thus can be backed up/generated by a dotfile manager like chezmoi/Nix) and if so under what circumstances. Using rustup default to change the settings might look surprising because one may expect that only rustup set can change it.

version is kind of meta, but it feels to me like all of default_toolchain, profile and auto_install are more "configuration" then "state", in the sense that they're only ever changed by the user (rather than changed by rustup "behind the scenes"). IMO that is somewhat independent from if they're set only via the CLI or directly with an editor.

[rami3l]

It seems that, following cargo's convention, a lot of cargo's config should have env var counterparts. Should rustup move more or less towards that direction?

Can you be more concrete about what you mean with this?

@djc A lot of cargo configurations can be changed by either env var or config.toml. As stated in the docs:

For example the target.x86_64-unknown-linux-gnu.runner key can also be defined by the CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUNNER environment variable.

If we are pursuing consistency within the Rust tool suite, this might be a direction worth investigating.

[djc]

IMO any work here starts with gathering up all the environment variables we currently look for, all the configuration we store, and then coming up with some heuristics for what is a good path forward for this stuff.

I'd be hesitant to follow Cargo on this without a better understanding of their rationale for this design. It feels like just adding more complexity without anyone really asking for it?