Stop nuking `$CARGO_HOME` (`~/.cargo`) on `rustup self uninstall`

[ollie27]

Surely it should only delete stuff that it created?

[brson]

Thanks for the report.

My reasoning for deleting .cargo is that rustup is responsible for the installation of the entire rust 'world', including cargo, so when it uninstalls itself (and cargo) it should uninstall everything. Everything in .cargo ultimately did originate from the rustup installation, if indirectly. I also don't know that there's much useful to do with .cargo if you don't have Rust.

I suspect that, for the average user who is ditching Rust, they really just want all of Rust off their system after uninstall.

I do see some use for being able to preserve both .cargo and .multirust. For example I uninstall and reinstall constantly while developing rustup and it's super annoying to reinstall the toolchains every time.

Another thing one might do with .cargo use use the bins from cargo install, but just copying out what you need to somewhere else before uninstalling is not too burdensome for what seems a niche case.

So I think it's a reasonable option, but not the default. I'm interested in other reasons for preserving .cargo after uninstall.

[ollie27]

rustup isn't necessarily the only rust install so it can still be useful to have the .cargo folder after removing rustup and it's toolchains.

People could be using ~/.cargo/config as a config to cover all repos in ~ and I don't think deleting people's hand written configs is very friendly. I would say that's more an issue in how cargo handles it's directories though.

In my case I just had to cargo install everything again after just trying rustup which I did not expect to have to do.

I think it should be optional but at the very least the uninstaller should be more specific about what its going to delete so you can backup anything you do want to keep. The installer is also a bit misleading as "You can uninstall at any time with rustup self uninstall and these changes will be reverted." suggests it will only delete things it created.

[brson]

Thanks for the further feedback @ollie27. I agree the uninstall message could be more clear and give options to not delete the cargo directory. For now though my inclination is still that for most users throwing away ~/.cargo is the right thing.

[Diggsey]

I think rustup now checks for an existing cargo on installation, so this shouldn't be an issue any more. @brson ?

[brson]

@Diggsey rustup will refuse to install over certain other rust installations, which might prevent some of the problem, but there's still no way to preserve .cargo during uninstall.

[epage]

This came up at the All Hands when discussing XDG path support. Users may want to specify their binaries should go in ~/.local/bin. At that point, we shouldn't delete everything in that directory, but only what is managed by rustup.

This means we'd at least be leaking cargo install binaries. We should probably go ahead and do this for all user data files. This may include the rustup config.

We should at least give a message to the user that we leaked files.

[Cloud0310]

I would like to fix problem as my startup project for GSoC, @rustbot claim.

Here's the proposed solution by @rami3l on zulip side:

The suggestion solution is: use the "same file" check already existing in the codebase to see if a file in the bin directory is a rustup link, and only remove the links. If after this step the bin directory ends up empty plus we are using the non-XDG directory config mode, remove the bin directory. This should allow the smooth transition to the XDG directory config mode.

Thanks for this solution here, I would try to implement these logic.

As for the potential risk of removing the tools (e.g. install rust-analyzer or rustfmt via mise instead of rustup) is fine as long as other tools don't try to make the binary install to .cargo/bin.
Even if this happens, I guess the same file logic, which is actually checks if the tool binary is a link to rustup, which making sure it's managed by rustup.
If there's any potential bugs, please let me know. I would like to investigate around.

[epage]

Some possible corner cases

• a race condition where a file gets written between the "empty" check and deletion. Likely deletion shouldn't be an error. In that case, I think deleting a directory can only succeed if it is empty, so you might be able to just skip the check, remove the directory, and ignore the error (or rather log it)
• I'm unsure under what conditions different OSs or other tools drop random files in directories (I feel like macOS is the main case that gets brought up). Depending on the behavior, that might prevent deletion-on-empty.