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
for rustup
, 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.