Add rust-analyzer to template?

[georgefst]

The one thing stopping me from being able to just run nix flake init -t github:ipetkov/crane#quick-start and instantly start hacking away on non-Nixified Rust projects, is having to manually add rust-analyzer to buildInputs. Is there a reason this isn't included?

There were some references to difficulties here on #378 and #383, but I didn't quite follow and I don't know whether they're still relevant.

[ipetkov]

Hi @georgefst, the main reason is I don't think that rust-analyzer belongs in the devshell so I didn't include it in the templates! That said the templates here are meant to be quick starts, but not necessarily authoritative, if you disagree with my reasoning you're always able to create and publish your own template and use nix flake init -t github:georgefst/your-templates#etc and use that instead!

---

Why I don't think rust-analyzer belongs in a devshell: IMO it is much closer to something to be integrated with your editor and less something which should be tied to the project toolchain (even if rustup has components for distributing rust-analyzer). Having it in a devshell can be useful if you use something like (neo)vim to edit, but more app-like editors (e.g. VSCode, etc.) either need to be started on from inside of the activated environment (e.g. code .) or configured in other ways to actually pick up the version of rust-analyzer that is specified in the devshell.

In my own experiences I've found that this can cause more friction than it solves: for a while I was using a nightly version of neovim for its LSP support, and things were sometimes things would break if I found myself in a situation where a project was pulling in a stable toolchain's rust-analyzer (older than what my editor expects) and I had to go out of my way to undo that "helpful" addition. Not to mention that if you check out an older version of your project, the devshell will correctly use an older rust release, but might also force you on an older rust-analyzer and cause your editor to go haywire if its somehow not compatible with an ancient version.

Feel free to include it in your own projects if you find it helpful, but I hope this answers your question!

[georgefst]

Okay, thanks! I'll try just installing rust-analyzer globally.

I think maybe I'm carrying over too many assumptions from Haskell, where the LSP server is tightly tied to the compiler, and has to be compiled with the exact same version. I'd also sort of wanted to keep tools for languages I don't use that often out of my NixOS config, but come to think of it, I'm specifying the Rust VSCode extension there, so that's pretty much moot.

[dpc]

So far I've been installing rust-analyzer in dev shells, but after reading the @ipetkov 's argument, I guess he's right? I'm a heavy CLI user, so indeed I kind of expect the whole dev env to be locked, but indeed it's not much of a benefit anyway, and most devs will use their own rust-analyzer from their external text editor anyway, so it's somewhat pointless.

BTW. Using two different toolchains sharing ./target: e.g. one being triggered by the VSCode the other by cargo check in the dev shell, causes continous full rebuilds which users (devs) often confuse with "Rust compiler being slow" and not attempting to improve. Ideally code editors would respect dev shell's or .envrc's but in my experience they often don't or it is incomplete/broken w.r.t e.g. from Rust plugin's rust-analyzer using the settings from the dev shell. The best workaround we've found is setting CARGO_BUILD_TARGET_DIR to $(pwd)/target-nix inside the dev shell's shellHook, so it does not conflict with the default ./target that outside software will use, so they are at least not constantly invalidating each other.

[ipetkov]

@dpc that's kind of what the rust-analyzer.cargo.targetDir setting is for, set it to true and rust-analyzer will use target/rust-analyzer as its artifacts directory, no need to manually set it in devshells and the like ;)

[dpc]

@dpc that's kind of what the rust-analyzer.cargo.targetDir setting is for, set it to true and rust-analyzer will use target/rust-analyzer as its artifacts directory, no need to manually set it in devshells and the like ;)

Yeah, but then every single dev would need to do it in their own editor. Which they won't because most will not even know there's any issue except "Rust is slow to compile".