@Nover, definitely the concept of remote development is killer, I use VSCode remote almost every day. Jetbrains’ brand of remote in its current state is still a bit flaky, but if you don’t need the flaky bits in your everyday use, I’m sure it’s just as killer; my setup relies on the bits that are still flaky, unfortunately.
Regarding your packaging effort:
As you discovered, because the Gateway downloads the client on-demand, it is of course not patched for nix, and fails to launch.
If you take a look where the client is actually downloaded and run from, it’s in ~/.cache/JetBrains/JetBrainsClientDist/JetBrainsClient-<version>-ide/JetBrainsClient-<version>/
(unless you have a custom XDG_CACHE_HOME
).
In that directory, there is another collection of shell scripts (i.e. bin/intellij_client.sh
, bin/jetbrains_client.sh
), as well as another bundled JDK (in jbr/
). If you look at those scripts, they by default use the bundled JDK, but they also respect an environment variable JETBRAINSCLIENT_JDK
.
The bundled JDK is the jetbrains-patched JDK that’s already packaged in nix as jetbrains-jdk
.
I think if you set the environment variable in your derivation makeWrapper
before executing the Gateway itself, the downloaded Client will respect the variable and everything will just kinda-mostly
work:
--set JETBRAINSCLIENT_JDK="${jetbrains.jdk.home}"