Since non-Arch users may have ideas about the solutions to packaging rustup in distros I’m producing my post there here as well.
Hi. I’d like for rustup to work cleanly when packaged by distros, but haven’t put much effort or thought into it. There are a variety of concerns expressed here and I’m not familiar with the details of arch’s rustup packaging, so let me just brain-dump, and feel free to correct me and respond liberally.
Issues with rustup distro packaging
-
Where does rustup get installed to? Stock rustup wants everything in
~/.cargo/bin
, including the rustup bin and its proxies. Distros may be inclined to put them in /usr/bin, and this is probably the correct thing to do from their perspective. I don’t see an obvious reason that wouldn’t work forrustup
, but not so for rustc/cargo… -
If rustup proxies are installed to /usr/bin how can they co-exist with distro-installed rustc/cargo? Both bins want to be installed there.
-
Even if the rustup proxies and the rustc/cargo bins can coexist on disk, how can somebody live in the rustp world while still using the system-installed toolchain? I think it makes sense to reserve a “system” toolchain name in rustup for this purpose but haven’t thought it through.
-
rustup self-updates are incompatible with distro packaging. For this we already have the “no-self-update” feature. Is there any more to be considered here?
-
rustup-init installs some toolchain by default. It is generally desirable to be able to install rustup without installing a toolchain. Having “system” be a valid toolchain would be one way around this limitation, in lieu of having a way to say “don’t install a toolchain”. It looks to me like this is not an issue for distros since their packaging just drops rustup and its proxies directly where it wants without running the rustup installer (basic rustup install is purposely simple like this).
-
Interaction between packaged Rust software that expects particular versions of rustc and rustup is bad. If Rust software wants to depend on rustc 1.10 it can do this traditionally via the package manager, but there is no way to express this if rustup is controlling the rustc version. Tricky issue.
-
The above case is most obviously manifested when building packages from source written in Rust. These expect to be built by the system’s toolchain. There may be ways to signal to rustup that these compilation scenarios should automatically use the “system” toolchain. e.g. if the source of these packages is always built in a specific subtree, there could be an override set on that subtree that tells rustup to use the "system" toolchain. Some complications here in the current design since you can’t just drop a configuration file into the tree itself to configure that like with rbenv.
-
rustup doesn’t have an option to install toolchains globally. Desirable feature, but needs careful design, haven’t put much effort into it.
Thoughts
To the suggestion of installing the rustup proxies as /usr/bin/{cargo,rustc}-rustup. This poses several difficulties, that I’m inclined not to do it. First, usability-wise it means that rustup users need to know to type cargo-rustup when working in Rust. This is pretty counter to rustup being a transparent drop-in for cargo; and I expect that if you install rustup it’s because you want to be in a rustup-world. Second, tools (primarily cargo) expect to be able to invoke rustc, etc. as ‘rustc’, and in rustup-world that rustc should be the rustc proxy. There are potential solutions to this, but I’d rather avoid.
There are some problems where it’s tempting for rustup and the system package manager to communicate about the active toolchain. I’d like to avoid this if at all possible. Very complex.
The idea to install rustup without its proxies is doable, but rustup would be quite crippled. It does break the primary functionality.
There will likely be situations in the future where rustup wants to create and
delete proxy bins dynamically. This could change the calculus of the issues
here in ways I’m not sure about yet, but istm the problems are not major -
rustup will just create those proxies in ~/.cargo/bin
as if it was doing
cargo install
.
I like the idea of a “system” toolchain where rustup can search the PATH for a copy of the tool it isn’t managing and defer to that, but the obvious problem is that both the rustup package and the rust package want their bins to be installed at the exact same place. I think if that issue is solved there is some path forward for solving the others.
Is it possible for the rustup package to modify the system-wide PATH variable? One solution would be to let the “normal” rust packages have the sweet /usr/bin location on the file system, and just put rustup somewhere else, with PATH precedence. Then let rustup defer to the system rustc via the rustup "system" toolchain, have rustup modify the override for the system package build directory to use the “system” toolchain during its install.