lsp-docker VS rust-overlay

I believe this has cost me a ton of time but I did learn a lot along the way. lsp-docker highest level function is lsp-docker-start. It calls lsp-workspace-root which calls buffer-file-name which, if starting from a dired buffer, returns nil so lsp-workspace-root returns nil and the LSP server is not started.

I'm trying to figure that out right now. There is lsp-docker which is designed (I'm still half guessing) to have a separate container hold the language server. What I want is a pre-existing container to hold the server. There is partial code in that repo to do that but it appears not fully baked.

If you're on WSL, you may want to take a look at something like lsp-docker which bypass all quirk of Tramp and works directly with your files in WSL. I've never been able to make Tramp work reliably (too much hanging with or without lsp-mode) from Windows -> WSL so bypassing it provides a much better experience.

This is a reasonable point, and something that is being worked on. I definitely think Docker can provide LSP servers as necessary, we're just not quite there. This is something that I'm interested in working on, though I'm not the only one: https://github.com/emacs-lsp/lsp-docker

Yeah, I'm a NixOS user, and nix helps a lot with managing LSP servers on my system at the point that this is not a issue for me, but I agree a solution runing then in a docker or something would fit nice as well, we already have this conecpt: https://github.com/emacs-lsp/lsp-docker/

[0] https://github.com/emacs-lsp/lsp-docker#docker-over-tramp-tbd

I'm trying to understand overlays in order to make a proper rustup install (I've read that this overlay is the best way to go).

real-world example: https://github.com/oxalica/rust-overlay/blob/master/flake.nix

In this language context specifically, if one wanted to manage their workspace with Nix I would reach for Riff and/or oxalica/rust-overlay first, since they are deliberately more aware of Rust-specific nuance. In the latter's case it has compatibility paths with rustup-toolchain files as well, for allowing your peers who can't or won't adopt Nix to continue to feel like first-class participants in the project. Another alternative I don't have experience with would be nix-community/fenix.

p.s. I'm not sure if it's mentioned much of anywhere, but it'd be neat if there was a way to figure out the appropriate cargo from a rust-toolchain/rust-toolchain.toml if present, ala https://github.com/oxalica/rust-overlay. Funnily enough 95% of my development time is in Rust, but I don't actually have it installed globally, fun times being a NixOS user. I'd definitely make the argument that cargo is an external dependency!

Many of us have moved to https://github.com/oxalica/rust-overlay over Mozilla's overlay.

We added rust-overlay, so we can easily specify different rust versions without relying on nixpkgs to give us what ever rust version in there.

If it's Rust, you can use https://github.com/oxalica/rust-overlay to get any version you want very easily without pinning an instance of nixpkgs just for it.

asdf does not allow you to keep three different versions of the same language, so I'm not sure how that compares? It's not super-trivial to do in Nix, but at least you can do it.

asdf is also no different than Nix when it comes to minor/major versions. You're at the mercy of what the plugin does, other than that you have to create your own plugin from scratch or make a fork. Nix has the option to patch things up more easily at least.

How does this compare to https://github.com/oxalica/rust-overlay/ ? Can fenix ingest a rust-toolchain file and provide packages from it?

Can you say a bit about how this compares to oxalica’s rust overlay?

I frequently try to do something, say use (from the README of rust overlay):