Deduplicate toolchains, components and/or artifacts #4663
Description
Problem you are trying to solve
It happens from time to time that the user gets confused about why rustup toolchain install stable, rustup toolchain install 1.92 and rustup toolchain install 1.92.0 require separate and duplicate/redundant downloads when they are essentially the same thing (given that the current stable is 1.92.0).
Such reports include:
- rustup run 1.9.0 is not an alias for rustup run stable when stable version is 1.9.0 #555
- pinning version with rust-toolchain to stable causes redundant download #1974
- Don't download duplicate nightly #1366
- rustup redownloads already installed toolchain #2617
The status quo is very well explained in the quote below:
Firstly, 1.70 and 1.70.0 are not the same toolchain. They might be on a given date, but once 1.70.1 releases, they are not.
Secondly, the installed components are currently defined as separate for each toolchain; adding a component that isn't expected might be strange and conceivable a bug for some developers - and turning minor versions into symlinks to concrete versions will have that effect, as you would no longer have separate component lists.
#1366 (comment)
In short, 1.92.0 is a "fixed target" that will always be pointing to that very version of the toolchain, but the other two are "moving target"s: 1.92 will be upgradable to any later 1.92.*, and stable to any later stable. These toolchains are logically separated and I have no intentions to change that, but physically this separation is not an absolute must.
Solution you'd like
A potential solution is to borrow from PNPM and use hard links or junctions that reference a user-global artifact pool. This might have some interesting interactions with multiple proposals, e.g.
- Tracking: Ensure the integrity of toolchains, handle concurrent reads/writes #3937
- Tracking: Concurrent Rustup #731
- Support virtual toolchains to "mix and match" components #4636
Another choice could be providing a user-global component (or even toolchain) pool instead of an artifact pool, depending on the flexibility we'd like to achieve.
I personally think choosing the toolchain pool is a bad idea since it turns out sometimes multiple toolchains share the same component esp. when they are not updated.
Notes
No response