For various reasons, I’m writing my own rustup-alternative named rustbud. While some things will necessarily differ (otherwise it wouldn’t be a separate tool!), rustup and rustbud will likely have a lot of things in common, like “reading a channel manifest file” and “extracting installable files from an archive”. These could conceivably become library crates shared by rustup, rustbud, and any other tools that might arise in future.
Recently, I published a crate called rust_release_channel which contains structs representing the contents of release channel manifests, along with all the magic Serde juice to read and write them. Compared to the equivalent code in rustup, there’s more documentation, stricter types (actual
chrono::NaiveDate fields instead of strings everywhere), and validation returns all the problems found at once, instead of just the first.
I don’t expect the rustup maintainers to rush out and add a dependency on a third-party crate with a single release and 12 downloads, but is there any appetite at all for sharing crates for this kind of toolchain package handling? If so, would rust_release_channel (in its current state, or with changes) be useful? What could I do to make it more suitable?