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

[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 Consider moving to platform-specific configuration directories #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)

[workingjubilee]

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

[workingjubilee]

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]

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.

[lgarron]

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]

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.