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.

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

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

it's on the passthru vscode.unwrapped

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

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

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?

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.

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

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

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

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/.

what gcc issues are you having?

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

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

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

@buckley310 please try again

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

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

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

@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.

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

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

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

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.

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

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.

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 :)

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)

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

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?

yes