VScod{e,ium} users: You can now use extensions without explicitly packaging them in nixpkgs

vscod{e,ium}-fhs is now available on master

BLUF: Most vscode extensions should “just work” without additional nixification.

Original motivation was while I was still working at Microsoft, and a document repository they created heavily relied on vscode extensions to give users feedback about how documentation should be written. I didn’t feel like packaging all of the one-off extensions they recommended, so I looked toward buildFHSUserEnv for a solution.

Later, I became frustrated with vim + rls (rust language server) integration, and tried my hand again at making vscode a decent rust dev environment using buildFHSUserEnv and got to a satisifactory level of usability and extensibility in #99968.

The original behavior of the vscode and vscodium package should be unaffected by these changes, the fhs variant is exported through their passthru attrs.

Decided to make a discourse post, since this has been a pain point for users for the past 2 years.

Added some documentation to the wiki on usage.

EDIT: forgot to mention why this package is relevant :slight_smile:

12 Likes

Hello Jon,
I will try this definitely.


Only a stupid (side note) questions regarding “reproducibility”

I’m not sure if I could follow @FRidh with his statement / the general “rules” of nixos regarding this topic (and a future strategy … )

Only the vscode editor is really reproducible in the use case. Otherwise the extensions will have to be managed outside of nix. However, it’s also compatible with the existing vscode-with-extensions paradigm, so you can mix and match if needed.

Essentially it will give users the ability to use vscode as if it was on another distro. There is a little bit a pain if a package required dependencies not already available (kept the base packages pretty small to reduce closure bloat), then the user would need to know which shared libraries come from which package, and use -fhsWithPackages to then bring those in.