vscode.fhs: add buildFHSUserEnv wrapped version

[jonringer]

Motivation for this change

Extensions commonly use pre-compiled binaries which aren't
aware of the nix store. Using buildFHSUserEnv will allow
for a more "natural" usage of vscode.

EDIT:
To not break users due to FHSUser regressions, I'm instead adding this as a passthru to the original vscode/vscodium flavors.

closes: #73810
closes: #91179

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[buckley310]

This opens and mostly works for me, although unfortunately the UserEnv also applies to vscode's integrated terminal, which would basically break that feature for me. Not sure if that can be fixed.

[mebubo]

I'd like to keep using the unwrapped version. Would it be possible to make this overridable?

[jonringer]

I'd like to keep using the unwrapped version. Would it be possible to make this overridable?

it's on the passthru vscode.unwrapped

[jonringer]

I'm in no hurry to merge this, and it could probably be improved to support the other use cases. Meant for this to be more of a discussion than anything else

[buckley310]

Using the unwrapped version seems good enough for me since I already got my plugins working natively.
It does seem desirable to have plugins working out of the box, though. That did cause me some trouble early on.

I wonder if it would be a good idea for discoverability if the unwrapped versions of vscode/vscodium were added to all-packages, so that they would show up on https://search.nixos.org/packages

[jonringer]

the other option would be to expose vscode-fhs, but I'm not a big fan of that.

@buckley310 can you give some steps to repro the terminal breaking?

[buckley310]

I have gcc in my systemPackages, but when I try and compile a C hello-world from the wrapped vscode terminal gcc returns

ld: cannot find crt1.o: No such file or directory
collect2: error: ld returned 1 exit status

The bash prompt itself is just the bash default bash-4.4$, some hotkeys (ctrl+arrows) and my aliases were not working as well since a lot of the global bashrc stuff doesn't apply to UserEnvs. Some or all of that might be fixable via ~/.bashrc, but I haven't tried.

[jonringer]

I'll try to see what I can do, it would be nice for vscode to "just work"

[jonringer]

@buckley310 do you mind trying again. I was able to get my terminal to be similar to my normal terminal

[jonringer]

@Atemu @illegalprime do you mind reviewing the bubblewrap changes?

[buckley310]

Bash interaction seems all good now.
Gcc issue is still present.
I actually noticed that SSL certificates seem to be problematic now, but maybe that one is just a missing bind in /etc/.

[jonringer]

what gcc issues are you having?

[buckley310]

echo 'int main(){return 0;}' >a.c ; gcc a.c

fails with

/nix/store/hiwz81i1g3fn3p0acjs042a4h5fri6dh-binutils-2.31.1/bin/ld: cannot find crt1.o: No such file or directory
/nix/store/hiwz81i1g3fn3p0acjs042a4h5fri6dh-binutils-2.31.1/bin/ld: cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status

[jonringer]

@buckley310 I figured it out, the unwrapped gcc gets put into the environment

[jonringer]

the libstdc++.so seems to be present even if I remove any mention of stdenv.

@buckley310 please try again

[jonringer]

doing stdenv.cc in targetPkgs does make gcc-wrapped available, but I (for example) don't normally have gcc in my path

[jonringer]

since I have buildFHSUserEnv sourcing your bash terminal. It should be inheriting from your normal shell

[jonringer]

pinging vscode extension contributors @eadwu @raboof @mcwitt @austinbutler @oxalica @veprbl

do you all mind testing this?

If you normally track unstable, this should be something like:

home-manager -I nixpkgs=https://github.com/jonringer/nixpkgs/archive/vscode-buildfhsuserenv.tar.gz switch

[veprbl]

@jonringer Just in case, I'm not a vscode user. I was only reviewing vscode PR's because it used to be that there was no one else to look at those.

[jonringer]

oh, then thank you for your contributions. Sorry for bothering you :)

[austinbutler]

Latest commit has resolved the zinputrc error, but still Git is not found. I do have my ZSH aliases though.

how do you have git installed?

I have it configured through home-manager, and it's able to be found

In home manager config in configuration.nix:

programs.git.enable = true;

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/new-users-using-nixos-wrong/9973/38

[jonringer]

decided to revive this. You can do

vscode.fhs
# or
vscode.fhsWithPackages (pkgs: with pkgs; [ rustup zlib ] )

to either have a minimal environment or one with additional tools that you only care to have a available for vscode.

Been able to use extensions and the terminal fine

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/500

[jonringer]

cc @FRidh @SuperSandro2000

In the current iteration, the existing behavior is preserved. People are able to use the fhs attr to opt-into the fhs environment. I think this is good to merge.

[SuperSandro2000]

I can't say anything about this because I don't use vscode in nix or know to much about bubblewrap.

[FRidh]

I saw you mentioned it as an alternative before but I did not comment that earlier. For discoverability you may want to make it a top-level package instead of a passthru attribute (vscode-fhs?) and extend or replace the description with a note saying how it is different. Both options are fine in my opinion.

[jonringer]

I saw you mentioned it as an alternative before but I did not comment that earlier. For discoverability you may want to make it a top-level package instead of a passthru attribute (vscode-fhs?) and extend or replace the description with a note saying how it is different. Both options are fine in my opinion.

did both :)

[turion]

Package descriptions can be improved

[jonringer]

Well, 7 months later, I think this is a good compromise. The original unwrapped workflow hasn't been altered in any fashion, but users now have the option to use extensions freely within vscode.

Extensions which require additional dependencies can be added with the vscod{e,ium}-fhsWithPackages to create an fhs environment with additional depedencies (e.g. rustup)

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/vscod-e-ium-users-you-can-now-use-extensions-without-explicitly-packaging-them-in-nixpkgs/12846/1

[CMCDragonkai]

If I install vscode-fhsWithPackages into my nix-env user profile, does that mean I can install extensions directly from the vscode IDE and not use nix to install extensions? That is, are extensions mutable?

[SuperSandro2000]

yes