Add visual studio code editor

[mucaho]

This is the 3rd implementation variant as proposed in #14354. See that issue for details:

• Still need to adapt the configuration file, which enables a vital part of the application - the extension manager. Seems like it can stay FOSS even with the configuration file pointing at official marketplace.
• This PR downgrades current version of electron to be compatible with vscode. electron will have to follow vscodes version requirement in future. TODO: make seperate electron nix expression, just for vscode.
• This PR shifts the injection of shared library lookup paths from the wrapProgram utility to patchELF itself. The flag dontPatchELF is needed, because in the fixupPhase the added $out/bin rpath is automatically removed. Additionally, both dontPatchELF & dontStrip need to be set to false in order for the binary to run without segfault. TODO: Move patchELF to postFixup.

Things done:

• Tested using buildtime sandboxing (nix-build . --option build-use-chroot true -A vscode)
• Tested using runtime sandboxing (nix-shell -I nixpkgs=/path/to/vscode/branch --pure -p vscode)
• Built on platform(s)
  • NixOS
  • OS X
  • Linux
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip --against HEAD~2" from root of nixpkgs fork
  • dependent pkg electron compiles & runs
  • dependent pkg vscode compiles & runs
  • Tested using electron-quick-start
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

More

Fixes issue #14354

cc @travisbhartwell

---

[mention-bot]

By analyzing the blame information on this pull request, we identified @fluffynukeit, @gebner and @travisbhartwell to be potential reviewers

[vcunat]

The flag dontPatchELF is needed, because in the fixupPhase the added $out/bin rpath is automatically removed. Additionally, both dontPatchELF & dontStrip need to be set to false in order for the binary to run without segfault.

It's generally better to run patchelf in postFixup. That way you shouldn't need to disable the automating stripping and patchelfing. (Stripping a patchelfed file breaks it sometimes.)

[vcunat]

And 👍 for using RPATH instead of $LD_LIBRARY_PATH, as the latter e.g. "relinks" any child processes, etc.

[jagajaga]

Please write a more appreciate description.

[mucaho]

Ok, thank you all for your input, I have applied the suggested changes.

[LisannaAtHome]

Why was vscode put into the "unfree" section of nixpkgs? What are the non-free components in it?

[gebner]

@ledettwy The binary distribution of vscode is non-free. The source distribution as hosted on github is licensed under MIT, but it cannot access the marketplace (i.e., the extensions) out of the box. It is not clear to me what would happen if we were to patch the open-source version to access the marketplace (you just need to modify a single JSON file).

The original vscode derivation (this PR) was built from source, but it is fundamentally broken since it needs to access the network during the build (#14447). The current tracking issue for the from-source build is #26698.

[LisannaAtHome]

It is not clear to me what would happen if we were to patch the open-source version to access the marketplace (you just need to modify a single JSON file).

Not sure what you mean. Free software that connects to non-free servers doesn't stop becoming free software. Browsers can have the capability to download extensions from the Internet and the browser is still free.

If you're concerned about the JSON file itself not being free software, doing a clean room implementation of that seems like it would be pretty straightforward.

[orivej]

The license of the binary build that we use says that "You may not … share, publish, or lend the software". This makes it unfree nonredistributable.

[LisannaAtHome]

Oh, so it's the binary version that's in unfree nixpkgs, and the source version (when it works) will go into the free nixpkgs?

[orivej]

Yes.