Long shot but worth it. I think I may have found my blocker for using #NixOS on my laptop/dev machines and am looking for help.

In short, I have multiple #Rust projects that build on the CLI just fine but not in VS Code/Rust Analyzer. I didn't spot this until very recently when I realized problems in my own code weren't being highlighted but compiled crates worked just fine.

Seems RA can't find some libraries but to the best of my abilities I've made those libraries available to the shell. I also launch code . from the terminal so it should have the environment set up correctly without need for Nix-specific extensions.

It's been suggested I not use the code-fhs Nix package, but that means starting from scratch and fixing existing extensions which work.

Please don't suggest abandoning VS Code or substantially changing my accessible workflows unless you also have 12 extra hours per day for me. Also please don't suggest abandoning Linux entirely--this issue is NixOS, not Linux.

More context: discourse.nixos.org/t/rust-pro…

in reply to Nolan Darilek

I'm not that familiar with vs code, but I believe that running code . from within the dev shell does not inherit the session itself, but I am not sure how you set up the dev shell.

I think direnv would read preconfigured .env/.envrc files and would not get the environment vars from the session.
There seems to be an extension for vs code named "Nix Environment Selector" that would let you select the dev shell file for an environment.

matthewrhone.dev/nixos-vscode-…

in reply to Nolan Darilek

Got a fix, in 2 parts:

  1. Install the VS Code direnv extension so my existing direnv setup automatically works in VS Code (I.e. it automatically downloads dependencies, sets up the environment, etc. without needing to be launched from a terminal first.)
  2. Start VS Code outside the project (I.e. from the myproject directory, cd .. && code myproject.

I guess my next question: is there a quick half-liner I can run to do something like nuke_it_from_orbit && code . to clear/reset the environment first? code . from the terminal is pretty thoroughly in muscle memory at this point.