Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustup toolchain list --verbose should list why each toolchain was installed #3919

Open
lolbinarycat opened this issue Jun 30, 2024 · 5 comments
Milestone

Comments

@lolbinarycat
Copy link

Problem you are trying to solve

a full rust toolchain is quite large, around 2GB. this puts the user in a tricky situation, where they don't want to have a bunch of extra toolchains installed, but they also don't want to accidentally delete a toolchain used by a project the use a lot, and then have to redownload it over slow wifi

Solution you'd like

either as part of the --verbose flag, or as a new flag (like list --why), rustup would display the reason that a specific toolchain was installed. if it was installed because of a rust-toolchain file, the path to that file is listed. toolchains installed before this update was made would have their reason listed as "unknown"

Notes

a possible improvment would be for rustup to track what rust-toolchain files reference a particular toolchain, although that would add significant complexity

@rami3l rami3l modified the milestones: On Deck, 1.29.0 Jul 4, 2024
@rami3l
Copy link
Member

rami3l commented Jul 4, 2024

@lolbinarycat Thanks for filing this issue! I think this feature request is quite valid.

Indeed, you'd like to have something like this as well especially when you're working with many different projects each with its own rust-toolchain.toml (although I first encountered this with our downstream elan).

However since this is doesn't look like a trivial change, correctly implementing this might require some more investigation... Please bear with us as t-rustup's current bandwidth is still quite limited 🙇

@djc
Copy link
Contributor

djc commented Jul 4, 2024

Yeah, I'm honestly not sure the implementation complexity of this is worth it. At the very least (a) I don't think it should be a priority for us and (b) this needs a good design to decide where this state gets stored.

@rami3l
Copy link
Member

rami3l commented Jul 4, 2024

Yeah, I'm honestly not sure the implementation complexity of this is worth it. At the very least (a) I don't think it should be a priority for us and (b) this needs a good design to decide where this state gets stored.

Just to add some context: I installed Lean 4 with rustup-derived elan. When I was maintaining a project that relied on mathlib4, the latter included a toolchain file. As I bumped it from time to time, the toolchain file also got updated, so I ended up with more and more versioned installations of the toolchain without a way to "prune" them... I imagine the same thing will happen with Rust projects as well.

@rami3l
Copy link
Member

rami3l commented Jul 4, 2024

Implementation-wise a basic idea would be placing an implicit.txt in the toolchain directory to signify that one toolchain is implicitly installed as required by one or more projects, with one toolchain file path per line.

If the file is missing or is empty, we consider the toolchain to be manually installed.

Finally, a toolchain can be pruned if it's implicitly installed and all paths in its implicit.txt are invalid. Otherwise, only the invalid paths are removed instead.

PS: This is neither saying I'm implementing it, nor meaning it's going to be implemented this way.

@lolbinarycat
Copy link
Author

Finally, a toolchain can be pruned if it's implicitly installed and all paths in its implicit.txt are invalid. Otherwise, only the invalid paths are removed instead.

you would need to actually parse the rust-toolchain files, since it might have changed to reference a different toolchain (this is extremely common for things like clippy)

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

No branches or pull requests

3 participants