Rls: tracking issue: easy install and go

[nrc]

I believe that for an alpha release the RLS must be easy to install. The current process is too high a bar for entry. There are two scenarios:

• Bare RLS - cargo install should just work and give a running RLS
• RLS inside VSCode - we should have a VSCode plugin that installs everything it needs - not sure if that means distributing RLS binaries or building the RLS from source.

Also cc #88 which needs to work out the box for a really good user experience.

[nrc]

SYS_ROOT env var is part of the friction: https://github.com/jonathandturner/rls/issues/80

[nrc]

Discussed:

• for alpha - cargo install should work (put RLS on crates.io, test)
• later, Rustup integration for downloading bins (no wait to build from source)
• VSCode plugin should shell out to either Cargo or Rustup to make this transparent to the user

[nrc]

Turns out that because we link the compiler, using cargo install with Rustup does not work for the RLS (https://github.com/rust-lang-nursery/rustup.rs/issues/765). So we need an alternative plan for the alpha release. We are likely to need two workflows one for devs and one for users. The latter will involve either rustup and/or binary distribution and should probably wait for alpha2.

[jntrnr]

Just to update. cargo install likely won't work as more people move to using rustup. Instead, we'll need to work on a rustup compatible solution. For the time being we'll use an environment variable to find the RLS: https://github.com/jonathandturner/rls/issues/112

[nrc]

Current plan is still to use rustup as primary installation mechanism. (cc @brson).

The VSCode plugin should be able to call rustup to install the RLS, the data it needs, and possibly even a compatible toolchain. If Rustup is not installed, the plugin should install it (with user consent).

[jntrnr]

Now installable through rustup.