You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
No way to prevent the Rustup installer from creating unwanted folders & files in the home dir #3256
I prefer to use Homebrew to handle all my toolchains, but I've heard a lot of good things about Rustup and gave it chance last week. However, I was unpleasantly surprised that the Rustup install process creates a whole bunch of files and folders directly in my home directory. There is an issue about following XDG conventions for config (#247), but this seems to be a broader issue. So far I've seen the following created, that I'm 100% certain all did not exist before:
~/.cargo, which requires $CARGO_HOME to avoid.
~/.rustup, which requires $RUSTUP_HOME to avoid.
~/.profile, which I do not use and do not want on my system.
~/.zshenv, which I also do not use and do not want on my system.
And just now, I found that using those env vars and deleting those dirs and files (and then reinstalling from scratch) wasn't enough — there's still a ~/.rustup/settings.toml file. Is it safe to delete? I specifically opted out of that folder, and now I have to research if it's safe to delete again.
To me, this is a horrible first impression. It suggests that Rustup is extremely callous about externalities and resource usage, which makes me wary of anything else it might do in the future. I've seen Python and Ruby installers break things often enough, and I'm really hoping Rustup won't be like them.
It's like I invited a contractor into my house, only to find they've installed something in the garage instead of the dedicated shed — and then installed a bunch of extra stuff around the house "just in case I need it" even though I very much don't need or want it. I would really appreciate if Rustup didn't do so, and I'd be happy to contribute fixes if I know they'd be accepted.
Steps
Run the installation command from https://rustup.rs/ on macOS, optionally with $CARGO_HOME and $RUSTUP_HOME set.
Possible Solution(s)
In order of respectfulness:
Ideally, do not create any home directory folders as part of the install process, even by/for other tools. If you want to create them, make it clear that you will and give a prompt to opt out / abort the install process.
changed the title [-]No way to prevent the Rustup installer from creating unwanted files in the home dir.[/-][+]No way to prevent the Rustup installer from creating unwanted folders & files in the home dir[/+]on Mar 8, 2023
@lgarron Your complaints are noted. I tried to implement a more conservative version of setting up the shell rcfiles. However, every time we tried to implement the more conservative version, it creates bugs, because not every terminal and GUI setup works the same way, and not every shell has created an rcfile, even when it is used. It would be convenient if all shells used a single rcfile for this sort of thing, but many will deliberately ignore .profile if another rcfile exists. Sometimes it varies on a distro-to-distro basis, as distros patch their GUI launchers and their shells. This makes it challenging to provide an installation method that does not fail immediately if the user is not a trained sysadmin.
The GUI launchers may not seem immediately relevant, but it is important that Rustup becomes available to tools that run it implicitly in the background while a user is in a GUI. So, we probably cannot comply with request 4. Please take up these complaints with the maintainers of Bash, Zsh, Fish, and... I guess POSIX? And also the distributors, I suppose.
However, setting up ~/.rustup and ~/.cargo (or the same at wherever else they are directed to install) are intrinsic to the functionality of Rustup, and request 1, "make it clear that so and so" will be created, has already answered. It is possible to still cancel installation at that stage of setup. Please do not issue demands for something you already have.
If you had run the rustup self uninstall command, the directories in question should have been removed automatically. Anything that did not get removed would have been safe to delete (indeed, the installation is more-or-less idempotent to begin with). But you say you did not. By immediately assuming that the software could not help you remove it, and taking it into your own hands, you removed the ability of that software to use its knowledge of what it had done to undo what has been done. We try to be careful about that. Please report any bugs in missed cleanup items.
If the XDG conventions were useful, they would be in use. Unfortunately they are in practice not, as demonstrated by the amount of deviation between distros as to whether they configure the software they ship to use it, despite being willing to patch everything else. So the consideration continues to be considered. Patches may be considered, but it is unlikely they would be accepted if they compromised existing functionality.
Your package manager can choose to ship Rustup and it is designed to function in such a case. However, many do not because they, too, often have a long list of demands, many of which have already been thought about and features implemented to make them possible, but the package managers refuse to investigate, think about, or otherwise use them. We cannot help in such a case.
On a personal note, I do not think that treating other people's work as todo items on your personal crusade is very respectful, yet you demand respect. Your message seems to be written without the consideration that other people have already tried to "fix" this. I am not pleased with what has become the current behavior by any means, but I still designed the prototype for it, because before it would simply fail to function at all if it was installed on a distro which even slightly deviated from the original creator's expectations. Notably, one that did not aggressively patch software to override its creator's design, but distributed it in fairly strict adherence to upstream code.
This led to an interlude of several weeks before I could get started again on writing any code. I had just started learning Rust at the time, and was still not familiar with the horrifying details of how shells work. "This slightly annoys me" is and should be a far lesser concern than "This does not work at all". Parody it all you want, but yes, I actually did need things strewn around to help, "just in case". Yes, some people need help!
Don't create shell profile files if they don't already exist, particularly if I'm not using the shell in question
Rustup explicitly asks during install if you want to create/update these files, and you are free to choose not to. If you are particular about how your profile is managed, then you should select "no" during installation and handle that aspect yourself.
It sounds like this kind of feedback is unwelcome here, even with an offer for me to invest time into helping. I will withdraw it and live with my workarounds.
I also wanted to drop in and apologize for the cranky tone of my initial post. It's clear that you've been thoughtful about tradeoffs, and that Rustup is operating at a level where you have to make technical tradeoffs with conflicting expectations. There is no active harm in the current behaviour, I don't bear any ill will, and I'm sorry for causing unnecessary strife.
I still run into this on a somewhat regular basis. I've made my peace with the fact that the default behaviour will probably never change, but I always have to remember to customize the installation and sometimes the wording on the interactive prompts confuses me.
I don't suppose there's a non-interactive/unattended way to install Rust using rustup without creating the unwanted shell profiles in the home dir? I've looked through the code a bit, and couldn't find a way to control it e.g. using an env var.
I don't suppose there's a non-interactive/unattended way to install Rust using rustup without creating the unwanted shell profiles in the home dir? I've looked through the code a bit, and couldn't find a way to control it e.g. using an env var.
@lgarron I believe this has been included on the roadmap as a part of the refined dir config project. We can potentially disable outputs like this explicitly shortly after the implementation is in place or, as a hack, you would be able to choose to dump the .env files into tmpfs/nullfs.
I don't suppose there's a non-interactive/unattended way to install Rust using rustup without creating the unwanted shell profiles in the home dir? I've looked through the code a bit, and couldn't find a way to control it e.g. using an env var.
@lgarron I believe this has been included on the roadmap as a part of the refined dir config project. We can potentially disable outputs like this explicitly shortly after the implementation is in place or, as a hack, you would be able to choose to dump the .env files into tmpfs/nullfs.
Absolutely fantastic! I'll look forward to that. 🤩
(Is there an appropriate way to keep an eye on that project so that I can try things out once they're ready?)
Activity
[-]No way to prevent the Rustup installer from creating unwanted files in the home dir.[/-][+]No way to prevent the Rustup installer from creating unwanted folders & files in the home dir[/+]workingjubilee commentedon Mar 9, 2023
@lgarron Your complaints are noted. I tried to implement a more conservative version of setting up the shell rcfiles. However, every time we tried to implement the more conservative version, it creates bugs, because not every terminal and GUI setup works the same way, and not every shell has created an rcfile, even when it is used. It would be convenient if all shells used a single rcfile for this sort of thing, but many will deliberately ignore
.profileif another rcfile exists. Sometimes it varies on a distro-to-distro basis, as distros patch their GUI launchers and their shells. This makes it challenging to provide an installation method that does not fail immediately if the user is not a trained sysadmin.The GUI launchers may not seem immediately relevant, but it is important that Rustup becomes available to tools that run it implicitly in the background while a user is in a GUI. So, we probably cannot comply with request 4. Please take up these complaints with the maintainers of Bash, Zsh, Fish, and... I guess POSIX? And also the distributors, I suppose.
However, setting up
~/.rustupand~/.cargo(or the same at wherever else they are directed to install) are intrinsic to the functionality of Rustup, and request 1, "make it clear that so and so" will be created, has already answered. It is possible to still cancel installation at that stage of setup. Please do not issue demands for something you already have.If you had run the rustup self uninstall command, the directories in question should have been removed automatically. Anything that did not get removed would have been safe to delete (indeed, the installation is more-or-less idempotent to begin with). But you say you did not. By immediately assuming that the software could not help you remove it, and taking it into your own hands, you removed the ability of that software to use its knowledge of what it had done to undo what has been done. We try to be careful about that. Please report any bugs in missed cleanup items.
If the XDG conventions were useful, they would be in use. Unfortunately they are in practice not, as demonstrated by the amount of deviation between distros as to whether they configure the software they ship to use it, despite being willing to patch everything else. So the consideration continues to be considered. Patches may be considered, but it is unlikely they would be accepted if they compromised existing functionality.
Your package manager can choose to ship Rustup and it is designed to function in such a case. However, many do not because they, too, often have a long list of demands, many of which have already been thought about and features implemented to make them possible, but the package managers refuse to investigate, think about, or otherwise use them. We cannot help in such a case.
workingjubilee commentedon Mar 9, 2023
On a personal note, I do not think that treating other people's work as todo items on your personal crusade is very respectful, yet you demand respect. Your message seems to be written without the consideration that other people have already tried to "fix" this. I am not pleased with what has become the current behavior by any means, but I still designed the prototype for it, because before it would simply fail to function at all if it was installed on a distro which even slightly deviated from the original creator's expectations. Notably, one that did not aggressively patch software to override its creator's design, but distributed it in fairly strict adherence to upstream code.
This led to an interlude of several weeks before I could get started again on writing any code. I had just started learning Rust at the time, and was still not familiar with the horrifying details of how shells work. "This slightly annoys me" is and should be a far lesser concern than "This does not work at all". Parody it all you want, but yes, I actually did need things strewn around to help, "just in case". Yes, some people need help!
So please. Stop insulting me.
Diggsey commentedon Mar 9, 2023
Rustup explicitly asks during install if you want to create/update these files, and you are free to choose not to. If you are particular about how your profile is managed, then you should select "no" during installation and handle that aspect yourself.
lgarron commentedon Mar 9, 2023
It sounds like this kind of feedback is unwelcome here, even with an offer for me to invest time into helping. I will withdraw it and live with my workarounds.
lgarron commentedon Mar 10, 2023
I also wanted to drop in and apologize for the cranky tone of my initial post. It's clear that you've been thoughtful about tradeoffs, and that Rustup is operating at a level where you have to make technical tradeoffs with conflicting expectations. There is no active harm in the current behaviour, I don't bear any ill will, and I'm sorry for causing unnecessary strife.
[lglogin.fish] Clean up after `rustup`.
[lglogin.fish] Clean up after `rustup`.
lgarron commentedon Aug 18, 2025
I still run into this on a somewhat regular basis. I've made my peace with the fact that the default behaviour will probably never change, but I always have to remember to customize the installation and sometimes the wording on the interactive prompts confuses me.
I don't suppose there's a non-interactive/unattended way to install Rust using
rustupwithout creating the unwanted shell profiles in the home dir? I've looked through the code a bit, and couldn't find a way to control it e.g. using an env var.djc commentedon Aug 18, 2025
I guess not, but that sound like a reasonable thing to implement. Want to try making a PR?
rami3l commentedon Jan 6, 2026
@lgarron I believe this has been included on the roadmap as a part of the refined dir config project. We can potentially disable outputs like this explicitly shortly after the implementation is in place or, as a hack, you would be able to choose to dump the .env files into tmpfs/nullfs.
lgarron commentedon Jan 6, 2026
Absolutely fantastic! I'll look forward to that. 🤩
(Is there an appropriate way to keep an eye on that project so that I can try things out once they're ready?)
rami3l commentedon Jan 6, 2026
@lgarron You will receive a call for testing from the "Inside Rust" blog when that is done, just like this time.
rami3l commentedon Jan 6, 2026
Closing in favor of #247.