3

I am new to NixOs and nix-shell and am still getting to know its idioms. Right now I have a Java project which I am using nix-shell via direnv to load up the build tool chain, including a jdk and bazel.

I would like the IDE - in my case ItelliJ - to use this same toolchain. My naive approach is to use a nix-shell script as follows, which is the default.nix in the root of my project, and the one picked up by direnv.

with import <nixpkgs> {};


stdenv.mkDerivation {

  name = "my-project";

  buildInputs = with pkgs; [
    jdk11
    bazel
    jetbrains.idea-ultimate
  ];

  shellHook = ''
    export JAVA_HOME="${pkgs.jdk11}/lib/openjdk"
    ln -s ${pkgs.jdk11}/lib/openjdk ./jdk
  '';
}

I can then launch IntelliJ with the following command from the shell:

$ idea-ultimate 2>1 > /dev/null &

While it works, I have the following concerns:

  1. Loading up the IDE into my command line shell seems really heavy, especially for the CI build.
  2. It is going to get worse as I add other IDEs the team uses, like Eclipse.
  3. It seems like the wrong way.

I can, of course, install these IDE packages using other Nix facilities, like home manager, which gives me the application launcher in the menu after the right config steps; however, I like directly launching the IDE from the shell to ensure the correct tool chain is in place and in correct paths.

My thought for a next step was to remove the IDE input from this default.nix and create custom nix files which include the inputs for the IDE and a launcher script to actually launch the IDE with nix-shell. My hope is that, if executed from the shell above, it will inherit its inputs, augment it with the IDE input, and then launch the IDE.

Again, my goal is to use nix to launch my IDEs, and use the packages and configs setup by the default.nix which is in the root of the project to ensure consistency.

Suggestions, including alternative approaches, are appreciated.

  • Does your CI build need to go through `shell.nix` at all? I usually have a `default.nix` for programmatic use, and rely on `shell.nix` only for humans (referring to the `default.nix` from the `shell.nix`, but not the other way around). – Charles Duffy Sep 14 '20 at 17:58
  • 1
    BTW -- if you haven't gotten a good answer here in a few days, I'd encourage you to post the question at over at https://discourse.nixos.org/ – Charles Duffy Sep 14 '20 at 18:05
  • @CharlesDuffy, Thank you. re: `shell.nix` vs. `default.nix`, I confess I don't know enough about Nix to answer this, but will follow up so I can learn more based on your suggestion. Any resources you can share would be helpful. Re: discourse.nixos.org. Will do if I don't get an answer here soon. – Ben Tomasini Sep 14 '20 at 18:35
  • A more promising approach is to load the environment via an IDE plugin. Here's an issue for [Jetbrains IDEs](https://github.com/NixOS/nix-idea/issues/1). VSCode has [Nix Environment Selector](https://marketplace.visualstudio.com/items?itemName=arrterian.nix-env-selector). Some IDEs may be able to load from [`direnv`](https://direnv.net/man/direnv-stdlib.1.html#codeuse-nix-code). Pinning an IDE is nice in theory, but not so well supported in practice, for example due to dotfile migrations or having only a single process+env for all windows. – Robert Hensing Sep 14 '20 at 19:55
  • @RobertHensing, that would indeed be great! Interestingly enough one of the commenters on the JetBrains issue is doing something similar to me as a work around: https://github.com/NixOS/nix-idea/issues/1#issuecomment-590942054 – Ben Tomasini Sep 15 '20 at 01:03

0 Answers0