Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Visual Studio Code editor #14354

Closed
mucaho opened this issue Mar 31, 2016 · 19 comments
Closed

Add Visual Studio Code editor #14354

mucaho opened this issue Mar 31, 2016 · 19 comments
Labels
9.needs: package (new) This needs a new package to be added

Comments

@mucaho
Copy link
Contributor

mucaho commented Mar 31, 2016

That's a code editor, developed by Microsoft.
There's already syntax highlighting for nix in vscode, but the vscode package itself is missing.

I got it working, but there are multiple alternatives how to package it:

  • download the binary directly, patchelf it, license = MS's unfree license
  • download the sources, compile them, during which the binary dependency electron is downloaded by their install script, patchelf the electron dependency, license = MIT
  • download the sources, compile them, adapt their install script to use electron from the nixpkgs repository (which is compiled itself, need to change the nixpkgs electron expression to do patchelf instead of wrapProgram with LD_LIBRARY_PATH), license = MIT
    Problem: vscode requires specific electron version - have a separate electron-vscode expression for that?

Wrapping electron with LD_LIBRARY_PATH env var is not possible, since vscode and electron modify the user environment (see microsoft/vscode#1033).
For licensing terms, see license explanation.
One (major) drawback of the FOSS version is that the extension manager is missing, which lets you conveniently install additional plugins. However, it can be easily enabled, by modifying a configuration file. Seems like that is allowed for the FOSS version.

Which alternative to choose? Is there another?

Patchelf looks something like this:

patchelf --set-interpreter $(cat $NIX_CC/nix-support/dynamic-linker) --set-rpath /nix/store/<hash>-env-atom/lib64:/nix/store/<hash>-env-atom/lib:/run/opengl-driver/lib:/run/opengl-driver-32/lib:/path/to/root/of/binary /path/to/root/of/binary/code

For atom-env, refer to electron's nix expression.

@vcunat vcunat added the 9.needs: package (new) This needs a new package to be added label Apr 1, 2016
@vcunat
Copy link
Member

vcunat commented Apr 1, 2016

In general, building everything from source is preferred.

@offlinehacker
Copy link
Contributor

But, good luck with that ;)

On Fri, Apr 1, 2016, 7:20 AM Vladimír Čunát notifications@github.com
wrote:

In general, building everything from source is preferred.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#14354 (comment)

@jgillich
Copy link
Member

jgillich commented Apr 2, 2016

I'm 👎 on building from source on this one. The extension gallery only works with the unfree version, and without it, the editor is just a glorified notepad.

@mucaho
Copy link
Contributor Author

mucaho commented Apr 3, 2016

Ah sorry for the misunderstanding, the (vital) extension manager can be enabled by adding merely 3 lines to a configuration file (I've somehow skipped that while skimming over the linked issue). Building everything from source is indeed the best option here.

@mucaho mucaho closed this as completed Apr 3, 2016
@jgillich
Copy link
Member

jgillich commented Apr 4, 2016

Amazing how some people can't just answer a simple yes/no question. Thank you very much for clarifying, and for packaging!

@mucaho
Copy link
Contributor Author

mucaho commented Apr 4, 2016

Oh noes! The hydra build for vscode is complaining while trying to download external dependencies with npm:

npm ERR! fetch failed https://registry.npmjs.org/...

I fear that this is by design and that a clean nix derivation may not access external resources, except for what has been defined as inputs (expression parameters + src files).

How should this be solved?
The node dependencies are shrinkwraped, that means the exact versions are specified for each (sub)dependency, which should produce a deterministic build. Is there some way to have npm install those dependency and let nix enumerate and hash the whole node_modules folder as a src dependency?
If there is no workaround, it will have to be repackaged as a binary :(

@mucaho mucaho reopened this Apr 4, 2016
@jgillich
Copy link
Member

jgillich commented Apr 4, 2016

@mucaho
Copy link
Contributor Author

mucaho commented Apr 28, 2016

Thanks to combined effort (#14891), vscode-1.0.0 should work now.
Assuming you have a nixpkgs channel setup which tracks the nixpkgs-unstable channel, and you have { allowUnfree = true; } inside your .nixpkgs/config.nix, you can install it via nix-env -iA nixpkgs.vscode.

@mucaho mucaho closed this as completed Apr 28, 2016
@freeman42x
Copy link
Contributor

freeman42x commented Aug 20, 2017

What worked for me was:

  • manually creating folder/file ~/.config/nixpkgs/config.nix and adding { allowUnfree = true; } to it
  • ~/.nix-channels needs to have channel https://nixos.org/channels/nixos-unstable nixos to get latest version of VS Code
  • run nix-channel --update after modifying the ~/.nix-channels file
  • running nix-env -f '<nixpkgs>' -iA vscode to install it
  • change KDE command line to code --user-data-dir=~/.config/Code/

Thanks to the helpful people in Freenode #nixos: rycee, Fare, sphalerite

@sid-kap
Copy link

sid-kap commented Jan 27, 2018

Is vscode no longer in nixpkgs? (Well, I get it in unstable but I don't see it at https://nixos.org/nixos/packages.html.)

@freeman42x
Copy link
Contributor

@sid-kap I installed it yesterday latest version using nix-env -i vscode-1.19.2
But for some reason it does not appear listed on the website search.

@vcunat
Copy link
Member

vcunat commented Jan 30, 2018

It's marked as unfree, and therefore hidden by default.

@evix1101
Copy link

I discovered that vs code was available on nix from this thread. If it's hidden on the website search, how should I have discovered it?

@jgillich
Copy link
Member

nix search

@AMDphreak
Copy link

It all needs to be searchable from the website. The website is the natural way to search and list packages, and is the de-facto standard.

De-facto standard
If a programming language has a package manager, it is the de-facto standard to put it online. So, too, must OSes with package managers but no App store. It is an industry-wide expectation.

The terminal is an inappropriate place to browse packages.
Use of substring and fuzzy search are not appropriate, if such a project has many plugins with its root-name in it, for example, "gnome". Search for a "gnome" package; if there was a package called "gnome" you would never find it among all the similar names. (assuming it doesn't get sorted at the top).

@puffnfresh
Copy link
Member

@puffnfresh
Copy link
Member

vscode is not listed there because it is unfree. NixOS by default is a free software distribution.

@AMDphreak
Copy link

AMDphreak commented Feb 27, 2019

vscode is not listed there because it is unfree. NixOS by default is a free software distribution.

(there are two ways your comment could be interpreted. I'm assuming the more controversial one, since it's 50/50)

You need to attract people to the OS. People use non-free software. Free/non-free is for the end-user to decide, not to be enforced by the distro. You're creating a very bad relationship between the distro and the end user. You live in a world full of non-free software. If you want to get rid of it, you must provide a better experience than the non-free software, and if you fail to do so, you must embrace each user's right to choose non-free software. It is not the distro's right to tell users what they can or cannot run on their system, or pose an unreasonable obstruction to those who wish to run non-free software (such as removing non-free software from search results). The free software community complains that Apple and Microsoft do this. The fact that they do the same is hypocritical.

@zopsicle
Copy link

I came across this issue in a web search for “nixpkgs vscode unfree” in the hope to find clarification. The licensing issue is now clear to me: Microsoft offers only an unfree build of their otherwise free code. To help future visitors I post this here, since it’s what Startpage/DDG point to.

It appears the vscodium package in Nixpkgs outputs a free build of VS Code, under the MIT license. There are some differences in the final product but those are only cosmetic, removal of telemetry, and the name of the executable. It also seems to be entirely up-to-date with the unfree version.

It would be nice if this somehow showed up if you searched for “vscode” in the packages page. Of course it doesn’t now, since “vscode” is not a substring of “vscodium”.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
9.needs: package (new) This needs a new package to be added
Projects
None yet
Development

No branches or pull requests

10 participants