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.
