Uninstalling `rustup` deletes `cargo-dist` installed packages

[epage]

Steps

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ apt-get update && apt-get install -y curl
$ curl -LsSf https://astral.sh/uv/install.sh | sh
$ source $HOME/.cargo/env
$ uvx posting  # works
$ rustup self uninstall
$ uvx posting  # fails

note: I've not run this but am basing it off of cargo-dist's generated install.sh and from rustup's source code: https://github.com/rust-lang/rustup/blob/c91692a1bdbd91663dbc5fbb1f1bdd684e711f1c/src/cli/self_update.rs#L908-L925

This is a fully reasonable set of steps. A user could experiment with rust and decide to stop but want to keep using their Python tooling that happens to be implemented in Rust.

Also, if I were making a product, I wouldn't want the implementation's language to be a part of our compatibility story

As a Cargo team member, I'm concerned about people mucking with Cargo's internals

[epage]

imo the CARGO_HOME parts of #41 should be rejected

#287 is a potential solution but I care less about how cargo-dist solves this and more about getting out of CARGO_HOME

[Gankra]

Great catch.

We are in fact working on this in https://github.com/axodotdev/cargo-dist/issues/1233, with the first steps already in flight to make it safe for us to do this migration. However we do need things like #287 to have a good safe default home for binaries on each platform.

This default made more sense when we were a rust tool for rust programmers, but, we've outgrown it.

It's worth noting that I believe cargo-binstall also does something like this, and possibly also cargo-quickinstall (the two are strongly related). But at least in those cases you're more explicitly engaging with cargo, whereas we can do it in some random curl-sh scripts.