Rustup backend does not detect missing components

[InnocentZero]

Basically the title. I came across this on a fresh arch install when I noticed the rust-analyzer was missing. Now, the way we handle missing packages is just by checking the keys, which does not suffice for Rustup (since the components are stored in InstallOptions and that is discarded).

One way to deal with this would be to convert them into an enum of components and toolchains, but I'm not sure how much of a 'hack' it'll be.

[ripytide]

I don't really want to make it a hacky method again like it was in pacdef, perhaps we could instead fix this by delegating the "is this package missing, and if so which bits do we need to install?" question to be have a per backend implementation. Something like:

trait Backend {
    fn missing(managed: Self::InstallOptions, installed: Option<Self::QueryInfo>) -> Option<Self::InstallOptions>;
}

[ripytide]

Also I don't like the managed variable name as it's a bit vague, perhaps we could rename it to required throughout the codebase?

[InnocentZero]

I don't really want to make it a hacky method again like it was in pacdef, perhaps we could instead fix this by delegating the "is this package missing, and if so which bits do we need to install?" question to be have a per backend implementation. Something like:

trait Backend {
    fn missing(managed: Self::InstallOptions, installed: Option<Self::QueryInfo>) -> Option<Self::InstallOptions>;
}

Yeah, this sounds good, and I was also thinking of "let the backend decide how to install things"

[ripytide]

I've nearly fixed this, but I discovered another bug with the approach, the rustup won't be able to remove unwanted components since the only removal method we have on the Backend trait at the moment is: remove(packages: BTreeSet<String>) but of course a single string is not enough information for a complex rustup toolchain. All of this goes to show in my opinion that rustup does not conform to the "all you need to install a package is its name and nothing but its name" but with rustup toolchains they are not so one dimensional.

All of this makes me feel as if instead of shoe-horning rustup into working with metapac (which would require a lot of complications to the Backend trait for the benefit of the rustup backend alone) we should instead just drop it since it doesn't conform the same way all the other package managers do.

I think if rustup packages are to be automated, that is best done by a bespoke tool and not a generic one like metapac.