Jetbrains Meta - nix develop, flakes, jetbrain ides

Help
1

Hi everyone

I was wondering what the “usual” way of running Jetbrains applications is. I’ve seen the wiki entry:
https://nixos.wiki/wiki/Jetbrains_Tools - which also seems to be a bit dated.

As for Jetbrains applications I see two ways of installing them.

  1. add jetbrains.<ide> into your configuration.nix somewhere. The neat part - everything is controlled by nix. Downside, the binaries might be less frequently updated, there can be issues with the jvm - according to some googling I’ve done, and it seems just a bit clunky to wrap these huge applications inside a nix package.
  2. add the jetbrains.toolbox and install all applications in ~/.local/... while this is not the “nix” way, you get the new releases as soon as they come out, the jvm and any dependencies are already bundeled with the application, so no wild goose-chase to track them down and installing them, and you get - while not nix’s version - of a checkpoint system to go back a version of the application.

I’ve personally made the decision to run with option 2. Simply because I’ve had these applications for some time now. I’m quite fond of them and (nothing against nix) but I don’t want to break a running system. As far as I see and understand, the vast options to configure those applications are also not captured with nix-options, so for the moment, I’m going to stick with the “all jetbrains” bundle with the toolbox being the only thing installed by nix.

The next question is the development environment. I saw that you can create an isolated environment for development in nix with nix develop and flakes (Development Environments on NixOS | NixOS & Flakes Book). This seems to be the way to go regarding software development of nix. And it also seems a bit neater than my current way of dealing with things e.g. Python: Having Python 3.10, 3.11, 3.12, 3.13 installed globally on my previous Kubuntu machine with all their dev dependencies, debuggers, … and then needing to manually select the right version if uv didn’t do so already, … I agree that dev envs where only the needed Python version and maybe some other stuff that’s relevant to working on my project, is a lot more beautiful than the global approach and this is something I would like to start implementing.

The problem I’m encountering are the Jetbrains applications.
Because the nix develop shell is a sandbox, I need to put e.g. Pycharm into the same sandbox. Inside that sandbox, I’d have python and uv, to set up my .venv/ and one of the things you can do in Pycharm - the Projects, is now completely useless. If the IDE is started in a 3.13 sandbox, but I’m working on a 3.11 project, I cannot use the Pycharm’s project switcher, I need to (stop the current version), launch a new shell with the right development sandbox and launch Pycharm in there. This seems doable but I’m afraid this might get tedious really fast and my big question is:

How is everyone else doing it?

  • Global Env?
  • One Pycharm Instance per dev shell?
  • Or is there some way I’m missing of attaching a “global” instance of Pycharm to a dev shell or even make it capable of starting the required dev shell?

Thank you so much for your input.

AS2k.

2

I’m using jetbrains ide almost daily on fedora+nix or nixos, for years now, I can relate to the problems you have. I use mostly intellij ultimate, some pycharm and rust-rover. I’ve settled for launching the IDE in the shell lacking for a better solution.

It’s indeed painful when I want to open different projects with different setup, though in practice it hasn’t been too tedious for me. Probably because I rarely need to make changes to multiple projects at once, usually I open the others to read/navigate.

It’s also annoying when the toolchains/build tools aren’t detected correctly, but it’s been slowly improving.

I’m using the jetbrains.<ide> packages from nixpkgs inside my dev shells (nix+fedora) or configuration (nixos). Like your “option 1”, I don’t care about latest version and the only time I had to switch to a standalone version was when I tried to use a debugger on a rust codebase a while back with the intellij rust plugin. Though I might have small issues that I don’t realize I could fix by using the toolbox.

1 Like
3

The solutions are different for each language, for python you can symlink the environment created by python3.withPackages into .idea/python-env (for example) and use that as the toolchain, for rust you can use weethet.bsky.social/mkShellRustRover at main , for java and other jvm based languages just specifying the JVM works

1 Like
4

Do you use the Jetbrains plugin system and did you encounter any issues with installing Jetbrains of community plugins (as in more recently)? According to the wiki, there are issues with plugins. I’m using number of plugins which I would also like to keep using. I forgot to add but this is also a major reason why I’m leaning more towards running with the toolbox alone.

5

You’re all looking at the unofficial wiki btw. This is the official wiki entry: https://wiki.nixos.org/wiki/Jetbrains_Tools

6

I have quite a few plugins in both setup (nix-on-fedora and nixos) and rarely have issues with them. I did not try the github copilot one but I used the opencode plugin via IntelliJ successfully by adding opencode to my nix shell.

I suspect the kind of problems you can expect are when a plugin hopes for a certain executable present in the PATH, the “usual nixos problems”. It can probably be solve by knowing what to add to your shell.

Jetbrains products tends to bring everything they need and keep their state in ~/.local/share/JetBrains and ~/.cache/JetBrains. Meaning it’s probably easy to switch from the IDE and toolbox setup, though don’t take my word for it.