There’s rewrite fish shell in rust discussion happening, and there’s this fine point being made about MSRV:
it's nicest when people who might just want to add a script that they want to test with the current state of the repo, who aren't really "into rust", can build it as easily as possible. And for people who aren't "into rust", the most straightforward thing is to use distro packages.
This seems like a very reasonable observation to me! The answer I want to give is
Readme should mention installing rustup package from the distro, and then rust-toolchain.toml would handle selecting the right version
However, while I know that rustup is packaged by, eg, NixOS and Arch, I don’t see a package for Ubuntu and Debian, the big ones.
What is the reason for that, why big distros don’t package rustup? Is this some ideological or architectural desire to not package package managers? Are there some specific technical issues with rustup which we can fix?
Or Fedora. Knowing Fedora better, I suspect it is more along the lines of shipping tools that the distro did not itself build using its guarantees. While rustup itself could be built fairly easily, its main purpose of shipping code that was not built by the distro (and being a much more "closed" set unlike the package hosting sites) can make it a harder sell.
The equivalents for python/node would be pyenv and nvm, though they both have a much more fragmented ecosystem with multiple tools available. On Arch it looks like pyenv is available in the main repositories, but for nvm you have to go to the AUR. Neither are available on Ubuntu or Fedora.
My understanding is that the blocker is still that rustup is a bunch of crates that aren't on crates.io because they don't want to be perceived as providing a stable API, and that makes it difficult to package.
I am wondering why is that a blocker? Like, rustc isn't on crates.io, and cargo isn't meaningfully on crates.io. It perhaps would be nicer to package rustup as you average crates.io binary like ripgrep, but packaging as an odd part of the bootstrap toolchain also feels fine...
I won't answer for others, but ... this may be related to perceptions (right or wrong) that rustup's goal is in direct conflict with the purpose of your typical packaging system (tracking dependencies, only having one version of a given package installed system-wide at a given time etc.).
There's perhaps the perception that a system-wide packaging system's purpose is to not encourage behaviour whih causes users to end up in a situation similar to what's described in xkcd: Python Environment
Important for @matklad's question about what rustup can do on the technical side to improve the packaging situation, this ITP mentions the download package as an issue.
Currently it's been patched out, but ideally it doesn't have to be. Both fedora and debian's tools have support for git dependencies, so the general blocker of rustup not being on crates.io is not relevant any more, but the download crate is also not there, which creates problems for these tools:
So ideally one would integrate the download crate into rustup.
The split was likely done to improve compile/iteration times. And doing this integration myself locally, it seems that it increases the cargo check time from 1.93 seconds to 2.13 seconds, so about 10% (talking about hot caches here, I first did cargo check, then added a blank line to the top of lib.rs to do the benchmark). Obviously this isn't great...
Alternatively one can only upload the download crate to crates.io, even if it's internal (issue for that has been linked up-thread). Maybe under a different name, idk.
Now, I'm definitely on the "manage all packages through a system package manager; say no to per-language package managers" side, but I don't think using rustup would make such a mess as that. I'm not familiar with Python, but I guess that kind of mess (of different ways of installing Python) results from having a longer history and having to learn from one's own mistakes, whereas Rust was able to learn from other languages' mistakes.
I still expect distros will use their own packaged versions of Rust and Cargo to build packages for the distribution. But packaging rustup remains incredibly useful: it chains the root of trust of Rust to that of various distributions, and it allows installing cross-compilation toolchains and nightly toolchains.
I'm not familiar with Python, but I guess that kind of mess (of different ways of installing Python) results from having a longer history and having to learn from one's own mistakes, whereas Rust was able to learn from other languages' mistakes.