VS Code + WSL

[d4hines]

Hi all,

My goal "stack" is Windows, WSL2, NixOS, DevOS, VS Code. The WSL2 distro here gets me most of the way there. There's also this nifty script patches the binaries used by NodeJS to be compatible with Nix. So using the two in conjunction, I can get VS code working as expected.

However, when I throw DevOS into the mix, it breaks. I'm hoping you guys can help me troubleshoot the issue. @sonowz commented that somewhere DevOS must be overriding stdenv, which is breaking his patch to NodeJS. Specifically, the library file libstdc++.so.6 is availalbe in the default config, but not in my DevOS config. I wonder if this has to do with flakes, since nix-env -i gcc works in the default environment, but not when I'm using DevOS.

I'd appreciate any help you guys can lend. The full thread with error messages and such is here: sonowz/vscode-remote-wsl-nixos#2 Hopefully once this is figured out we can include it a "WSL2 Profile" so this works out of the box 😃

[blaggacao]

sonowz/vscode-remote-wsl-nixos#2 (comment)

---

The key is to find out what environment exactly the script is running.

In a devos devshell, for example, a patched version of nix is in the path, that comes hard-wired with flakes support. That version might be api in-compatible with the script.

I also think flake-utils-plus removed setting the NIX_PATH since I guess we wanted to uncover silent upstream reproducability issues (such as this).

---

The best way forward, in my opinion, is to make this script available as a package that substitutes all necessary bins directly from pkgs, a la ${pkgs.patchelf}/bin/patchelf ....

That way, there is no need for indirections through a nix-shell and all the associated problems.

The file probably can be put in place with home-manager, since I understand it must go into ~. Although, if there is a system wide location where this file could go in, that might even be better.

[d4hines]

@blaggacao, thanks for the explanations, here and on the other thread - I'm new to this and appreciate the hand-holding 😅

So to review, we're running VS Code in Windows, which issues commands to the NixOS VM. The first thing it does is download a vendored version of NodeJS (this is very un-Nix, but VS Code devs aren't planning on changing it any time soon). Once it downloads its server, every time VS Code starts up and interacts with NixOS, it first runs the script in question. Also, VS code continually updates itself and its vendored NodeJS - thus, the script needs to attempt the patch every time.

Given this, here's my best guess interpretation of your suggestion:

• I'll create a Nix package does the same thing as the script, but with access to the correct pkgs:

   pkgs.writeScriptBin "patch-vscode" ''
     for versiondir in "$1"; do
       echo "Patching "$versiondir" "node"
       # Currently only "libstdc++.so.6" needs to be patched
       ${pkgs.patchelf}/bin/patchelf \
          --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" \
          --set-rpath "${stdenv.cc.cc.lib}/lib" "$versiondir""node"
     done
  ''

  • Question: will stdenv.cc.cc.lib be defined? I think so, since stdenv is included by default when building packages, right?
  • Question: I'm adapting this from https://nixos.wiki/wiki/Nix_Cookbook#Wrapping_packages, but I'm not sure what else is involved in packaging this. Is there a way I could include this inline in my DevOS config?
• I will then add something like this to my DevOS config:

  home-manager.users.d4hines = { suites, ... }: {
   # ...
   file = {
     ".config/vscode/server-env-setup".text = ''
     VSCODE_SERVER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
     echo "Got vscode directory : $VSCODE_SERVER_DIR"
     echo "If the directory is incorrect, you can hardcode it on the script."
     echo "Patching nodejs binaries..."
     patch-vscode $VSCODE_SERVER_DIR
     echo "== '~/.vscode-server/server-env-setup' SCRIPT END =="
     '';
   };
  };

How far off am I?

Appreciate the help!

[d4hines]

Ok, a friend pointed out to me that the only reason it wasn't working for manually was incorrectly interpolating the string of the path in the bash script. So I now have a minimal example working. This makes it plain that I could lift this to a home-manager file (without the nixpkg) and achieve the same declaratively. So that raises the question: what is the best way to distribute a "DevOS module"? I'm sure I can look through the community branch and figure something out, but I know there are a lot of changes in the works for DevOS.

[blaggacao]

Ok, so I've to be terse (on a hurry):

• You got the idea
• pkgs -> define them in ./pkgs similar to examples from community branch), they will be available as per the overlay name you give them in ./pkgs/default.nix, if you name it vs-code-startup-script, then it will be available as pkgs.vs-code-startup-script.
• with that in place, you can make a module that places e.g. a small bash wrapper for pkgs.vs-code-startup-script in the well-known place where you need it

I would check with the vs code docs, if the well-known place can be a system path instead of a path within the home folder. If that shows to be true, then there is no implicit dependency on home manager and you should be able to build that system path directly with nixos.

If that system path should reside within /etc, then its relatively straight forward with environment.etc."...".source, if it's in another place, I don't have an idea at hand and would have to research myself.

If it can't be a system path, then there is probably no way to make this patch user-independent.

---

Also, please suggest upstream to properly flakify the script. I think me or @Pacman99 or @gytis-ivaskevicius can be pinged.
VS Code on Windows-Nix is an exciting user base: iirc roughly 50% of all developers work on windows and probably most of them with vs code.

👍

[blaggacao]

PS: also research NIX_CC, not sure where that is supposed to come from within env ...