Add a facility to rustup to show how its variables are currently set.

Problem you are trying to solve

Currently there is (or I can find) no way to see how the "variables" in rustup are set. The rustup set command allows you to set them but it has no --list variant neither does rustup show have a --variables variant. To be slightly more explicit, rustup set help displays:

Alter rustup settings

Usage: rustup[EXE] set <COMMAND>

Commands:
  default-host      The triple used to identify toolchains when not specified
  profile           The default components installed with a toolchain
  auto-self-update  The rustup auto self update mode
  auto-install      The auto toolchain install mode
  help              Print this message or the help of the given subcommand(s)

Options:
  -h, --help  Print help

But I cannot display how default-host, profile, auto-self-update or auto-install are configured.

Solution you'd like

I have no preference as to whether this is a new variant of show or set or both or even some other solution. If we take Unix shell command set as the exemplar, then rustup set would show this rather than assuming "help" as it does now, but since that is a breaking change it may well not be the preferred solution.

Notes

I have discussed this on zulip and been advised to raise an issue.

@RodBurman

@RodBurman Thanks for reporting!

I do think your proposal of making rustup set default to printing what we have set is quite reasonable. Also we can have an explicit subcommand rustup set list to do the same thing to mirror rustup override which already has that.

Also, repurposing something that didn't work before for other purposes is not a breaking change AFAIK.

Context

Following the intuition from git it seems that rustup set foo without any value should print the current value, however it currently resets that value, not sure whether we should change that.

@rami3l

May be just me but set list does not feel like a nice way to do this, since it is not totally implausible that at some point we would add a command rustup set list=enable|disable or some such. Similarly I would not have added the option for a "naked" help command, given there is also -h and --help providing the same function, but too late (probably) to change that. So I'd go with and/or --list by preference. Having set X reply "X=" sounds good too, but again a change that alters, rather than just adds, behaviour so maybe a problem as @rami3l says.

@RodBurman

@RodBurman Thanks for sharing your ideas!

The rationale of help vs -h vs --help here is that we really want to support all options so users would to get basic help no matter which style they are used to in the past.

But apart from that I think it's quite unlikely to have configuration options named help or list so I believe we are pretty good here.

Maybe we should have something that shows a nice terminal display of all configuration plus relevant environment variables etc?

Maybe we should have something that shows a nice terminal display of all configuration plus relevant environment variables etc?

So, should the command to show the set variables and the RUSTUP_* environment variables be rustup set list?
What are your thoughts on something like rustup show variables?

While we are adding show commands I'd like a "show all" which shows all installed targets for all installed toolchains.

Maybe we should have something that shows a nice terminal display of all configuration plus relevant environment variables etc?

So, should the command to show the set variables and the RUSTUP_* environment variables be rustup set list? What are your thoughts on something like rustup show variables?

Both feel to me like they're overloading set or show with meaning that doesn't really make sense in the context of how they're otherwise used? I would suggest something like rustup config or rustup status or rustup info.

I'd agree show is maybe not the place to add the facility having said which, rust config sounds too much like how to set things i.e. current set, and status maybe too much like show i.e. what the installed software is, so my preference would be rustup info or previously suggested rustup set, displaying current position in the same way bash set does.

Seems pretty unintuitive to me that you're supposed to write rustup set when you want to query rustup's state.

Well that's the way unix shells "set" works and so does the Windows set command, so not truly intuitive but common and so maybe expected? To loop back to more or less where we started, since "set" currently has the effect "set --help", we could as some other switch like "set --variables (or --list)" rather than change the meaning of the unadorned set command.

+1 for rustup info, although I would not be opposed to rustup set --list either.
I'd be happy to implement this if that sounds reasonable.

@FranciscoTGouveia

Do we have a "benevolent dictator" for rustup, who can just dictate the UI or are we trying to reach consensus or does @FranciscoTGouveia as developer get the golden vote by just going ahead and developing "rustup info' (for instance)? If we are trying for consensus I will say I am quite happy with info.

@djc

@djc @FranciscoTGouveia I'm a bit lost here, is this command that you propose (rustup info or rustup config or whatever) intended for the settings only?

If so, my proposal would be that rustup set becomes an alias for rustup config set, and rustup config list would be doing what is suggested right now: printing the settings file.

PS: There seems to be a naming precision to be made: the old rustup calls it settings and it goes naturally with set. However rustup settings set is just weird. Maybe config or pref would be better?

@RodBurman

Do we have a "benevolent dictator" for rustup

@RodBurman That might be easier sometimes but I'm afraid we don't work this way here...

is this command that you propose (rustup info or rustup config or whatever) intended for the settings only?

If so, my proposal would be that rustup set becomes an alias for rustup config set, and rustup config list would be doing what is suggested right now: printing the settings file.

Initially, I envisioned rustup info as a command that would only display the user's configuration and RUSTUP_* environment variables.

However, I really like this idea of introducing rustup config, with rustup set acting as an alias.
Regarding the name of this new command, I would vote for config instead of info, as I believe rustup info set is somewhat confusing.

That said, I think we can converge on dropping the idea of extending rustup set with new functionality, right?
Instead, we could introduce this new rustup config command.

If so, my proposal would be that rustup set becomes an alias for rustup config set, and rustup config list would be doing what is suggested right now: printing the settings file.

Sounds okay to me, although I think we should also show (the impact of) environment variables that influence the running process.

Navigation Menu

Repository navigation

Add a facility to rustup to show how its variables are currently set. #4919

Problem you are trying to solve

Solution you'd like

Notes

Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add a facility to rustup to show how its variables are currently set. #4919

Description

Problem you are trying to solve

Solution you'd like

Notes

Activity

rami3l commented on Jun 21, 2026

Context

RodBurman commented on Jun 21, 2026

rami3l commented on Jun 21, 2026

djc commented on Jun 22, 2026

FranciscoTGouveia commented on Jun 22, 2026

RodBurman commented on Jun 22, 2026

djc commented on Jun 23, 2026

RodBurman commented on Jun 23, 2026

djc commented on Jun 24, 2026

RodBurman commented on Jun 24, 2026

FranciscoTGouveia commented on Jun 25, 2026

RodBurman commented on Jun 25, 2026

rami3l commented on Jun 26, 2026

rami3l commented on Jun 26, 2026

FranciscoTGouveia commented on Jun 26, 2026

djc commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions