lol it comes from this thread
Pearl:wgpu-rs mcc$ cargo --version
cargo 0.26.0 (41480f5cc 2018-02-26)
Pearl:wgpu-rs mcc$ rustc --version
rustc 1.25.0 (84203cac6 2018-03-25)
Those sound⦠kind of old?
This was from me running the rustup.rs/ script a couple minutes ago
2
1
nitter.vloup.ch/mcclure111/statu⦠has more details
Okay. Should I file this, and where? github.com/rust-lang/rust ? Unfortunately it may be my running of rustup update cleared the state that caused the bug.
1
1
lol
to be clear, there is a bug here even if .cargo wasn't deleted, the "fix the deleted .cargo" thing was the one part of the install that *worked*
(user experience wise, there are like three different scenarios to get here)
1
(but yes, if .cargo hadn't been deleted you would have been able to `rustup update` and be done with it, perhaps involving a `rustup self update` though i think that's automatic these days)
1
On a note unrelated to anything, "delete the whole package manager and try again" is a step I commonly perform as a *first* resort with other language package managers such as npm, opam etc. Maybe it would be nice if cargo or cargo clean had a setting for "reset cargo to newborn"
2
2
good point. @dsilverstone is the rustup maintainer and probably would have ideas for that.
The way I do this is deleting the _other_ folders in `.cargo` (not bin)
2
Yeah. The thing is if you're deleting subfolders like that you're doing something fiddly and maybe not-future-proofed. Like what if someday later you add a /lib folder that should never be deleted.
2
1
If I run cargo --reset-all or rustup reinstall or something and all that does is delete the folders in ~/.cargo other than bin, I can feel confident that whatever it did was "the recommended way", cuz cargo/rustup did it.
Anyway this is not very important.
1
`rustup self uninstall` will recursively delete all of `$RUSTUP_HOME` and `$CARGO_HOME` (or give it a good go at any rate)
May 14, 2020 Β· 4:20 PM UTC
1
1