Skip to content

No way to prevent the Rustup installer from creating unwanted folders & files in the home dir #3256

Closed as duplicate

Description

@lgarron

Problem

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:

  1. 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.
  2. Alternatively, follow XDG/platform conventions per Tracking: Support for platformdirs (platform-specific system directories) such as XDG Paths #247 by default, without requiring any env vars.
  3. Use $XDG_DATA_HOME if it's set.
  4. Don't create shell profile files if they don't already exist, particularly if I'm not using the shell in question (also see Install script tells me to source a sh-style env file when run in fish #3251, PATH support doesn't work for fish shell #478).

Notes

No response

Rustup version

rustup 1.25.2

Installed toolchains

Default host: aarch64-apple-darwin
rustup home:  /Users/lgarron/.data/rustup

stable-aarch64-apple-darwin (default)
rustc 1.67.1 (d5a82bbd2 2023-02-07)

Activity

  1. 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
  2. workingjubilee commented on Mar 9, 2023

    @workingjubilee
    Member

    @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.

  3. workingjubilee commented on Mar 9, 2023

    @workingjubilee
    Member

    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.

  4. Diggsey commented on Mar 9, 2023

    @Diggsey
    Contributor

    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.

  5. lgarron commented on Mar 9, 2023

    @lgarron
    Author

    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.

  6. lgarron commented on Mar 10, 2023

    @lgarron
    Author

    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.

  7. moved this from No maintainer feedback yet to Won't fix 😕 in Vanquishing dotfiles (or dotfolders) directly in the home dir 🧹☺️on Mar 22, 2023
  8. moved this from Won't fix 😕 to Semi-fixed: requires custom env vars in Vanquishing dotfiles (or dotfolders) directly in the home dir 🧹☺️on Mar 22, 2023
  9. lgarron commented on Aug 18, 2025

    @lgarron
    Author

    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.

  10. djc commented on Aug 18, 2025

    @djc
    Contributor

    I guess not, but that sound like a reasonable thing to implement. Want to try making a PR?

  11. rami3l commented on Jan 6, 2026

    @rami3l
    Member

    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.

  12. lgarron commented on Jan 6, 2026

    @lgarron
    Author

    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?)

  13. rami3l commented on Jan 6, 2026

    @rami3l
    Member

    (Is there an appropriate way to keep an eye on that project so that I can try things out once they're ready?)

    @lgarron You will receive a call for testing from the "Inside Rust" blog when that is done, just like this time.

  14. rami3l commented on Jan 6, 2026

    @rami3l
    Member

    Closing in favor of #247.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions