Hi Jakub, Jakub Kądziołka writes: > I don't think tools beyond rustc and cargo should be included in the > main rust package, as this causes them to be built in each step of the > bootstrap. I believe a better approach would be to define separate > packages for them. Yeah that would make sense. Have we explored any of the incremental or --keep-stage options to speedup the bootstrap? > We would have something like > > ;; TODO(staging): Bump this variable to the latest packaged rust. > (define-public rust rust-1.45) > > +(define-public rust-for-tools rust-1.50) > > I'm not sure if rustbuild can be convinced to not build the compiler > itself when the version used for the build is the same as the sources'. > If so, defining packages for each tool shouldn't need any guix-side > tricks. Even if it did build the compiler for each tool it may not be a problem if only the last 3 versions had the tools available (for instance). > Otherwise, I would define a single rust-tools package with > (outputs '("rustfmt" "clippy" ...)). Perhaps it would help with UX if > rust-tools itself was hidden, and instead the tools would be exposed > with simple packages that expose each tool separately, with a symlink or > similar. I could see this working nicely. I think this is just more evidence for language-environment related documentation. > I'll see if I can find some time to try this out this week. Thanks! That would be helpful. It is really painful to have all these unmerged patches to rust. Kindly, John