I'd like to cast my vote for inclusion in the repo. While I take the viewpoint that most software should be gotten through a distro's repos, proper tooling is very important. As this is the official rust toolchain installer, I think it's something that should be in the repo. Perhaps it can be installed as a programming.rust component?

I second @jschwanebeck proposal to have a programming.rust component. Along with the already exising rust and cargo packages, and the upcoming rustup, we'd also need rls and racer. How can we organize all this fragmentation? With a new component or maybe with a rust-tools package?

As long as it doesn't do anything like replace system binaries it can go in.

Arch package is working great, it can be used as base.

I'll tackle this. Just a couple questions for @ikey.

rustup can operate in a proxy mode (like ccache, distcc). In this mode, the user would only need to add /usr/lib/rustup/bin to their path (or this could be added to the default path by the package via a profile update?). The downside is if you have rustup installed, but not cargo/rust (or a few other utilities rustup proxies), you get an error instead of "command not found". Also according to the documentation, rustup will fall back to the "default toolchain". This doesn't seem to mean the system toolchain. Installing cargo and rust from the system packages still results in a toolchain not found error. I'm not yet sure if this is a bug or if "default toolchain" has some other meaning in this case.

The other way is to just provide the rustup binary. Users would then need to add $HOME/.cargo/bin to their path and manage the toolchains there themselves. The upside here is having the system package and rustup installed means fallback works properly.

I'm leaning tword the latter, but would like someone else's input.

It looks like it would take a bit of rewriting the cargo and rust packages, as well as the component or meta-package being created, but a custom toolchain could be created, which could be registered with the rustup binary as the default toolchain. See here.

I'd love to take this on. The only issue I foresee is that rustup also auto updates. Is it too invasive to make the rustup command be a script that copies the actual rustup binary (bundled as a part of the package) to a user's directory and echo 'export PATH=$HOME/.cargo/bin >> $HOME/.profile'?

The alternative is submitting a patch to rustup upstream that allows configuring it via an environment variable to look for newer versions in a user's home directory. I'm partial to the latter. Glancing at the rustup source it shouldn't be too difficult to do. RUSTUP_HOME and RUSTUP_UPDATE_ROOT already exist and seems to be how this could be done. Relevant docs here. Any thoughts?

Installing/Updating packages shouldn't modify config files inside $HOME at all.

Installing rustup to /usr and creating proper symlinks will make it download toolchains to the $HOME/.rustup/. Then you can just run anything and it will work like standard rustup.

The only issue I foresee is that rustup also auto updates.

When rustup detecs it's running from read-only directory it disables self updates so there is no problem at all.
Or you build it with no-self-update switch.

@jschwanebeck What you linked to is for utilizing a custom toolchain (think building a patched version of rust) from rustup. The toolchain is still managed in the user's home directory. So, while you could use this for the system rustc/cargo, it would still require each user to run rustup toolchain link... themselves.

In T5309#107838, @mati865 wrote:

Installing rustup to /usr and creating proper symlinks will make it download toolchains to the $HOME/.rustup/. Then you can just run anything and it will work like standard rustup.

I assume you're talking about proxy mode? Like I said, the issue here is it won't fall back to the system rustc/cargo (like the docs say it is supposed to) and just returns an error that no toolchain is installed. Once the user installs a toolchain using rustup, it works properly, but it's kind of silly to not fall back to the available system binaries.

FWIW, I already have this packaged, just waiting on someone to help decide which way it should be done (proxy mode or no).

I would argue for proxy mode, most of the documentation for rustup is written assuming that the toolchain is installed in the $HOME/.rustup/ directory and the amount of users that will install rustup but not a toolchain through rustup seems extremly small.
I like @livingsilver94 idea of including racer and rls in the repos, but would argue against a combined package "rust-tools". The arch package for racer and rustup solves this quite nicely.

It's been quite a while for this package and I don't think things are moving along as they should. @saintdev, do you plan to create the initial commit for this?

Have you made your decision on if it should be in proxy mode or...?