Add support for plugins patching and add nixpkgs patches

[SamueleFacenda]

fixes #171

I translated nixpkgs plugin ids -> plugin names, but I'm not sure (e.g. python-ce vs python).

[MattSturgeon]

How do you intend to handle differences between plugin/ide versions? E.g. if you have an override for (say) "com.jetbrains.rust" that ends up needing to be different on 2024.2 vs 2025.3

Also, does @theCapypara actually want to maintain per-plugin overrides in this flake, or would it be better to document how end-users can override plugin derivations themselves and/or link to a separate repo with overrides you wish to maintain?

If we do end up with overrides maintained here, and they are only maintained against recent plugin/ide versions, perhaps they should be made optional and not be automatically applied?

[theCapypara]

Thanks!

I am not against adding "special plugins", but I'm also not willing to maintain them :). (Unless I ever run across a plugin I need that needs it.)

So, a few thoughts so I can accept this:

• This needs documentation (in the README, etc.)
• The "overrides" need some metadata:
  • Who maintains it: I don't want any unmaintained overrides here. My suggestion is (since we are outside of nixpkgs) we keep this lean and just have a list of strings for this (GitHub usernames). Could maybe add some CI later based on this.
  • What version the overrides were tested against. This helps users if plugin updates break, even though there's currently no support here to install older plugins.
• As @MattSturgeon pointed out, this should be optional. There has to be some way to disable these overrides. They can be on by default, but there has to be some easy way for users to disable them on a per-plugin basis.
• Bonus: I guess it could be useful if users could inject their own overrides on a per-plugin basis

I translated nixpkgs plugin ids -> plugin names, but I'm not sure (e.g. python-ce vs python).

Does that mean you haven't tested them yet? You can find the plugin IDs that this flake uses on the bottom of the plugin marketplace pages: https://plugins.jetbrains.com/plugin/25044-stonecutter-dev -> "Plugin ID"

[SamueleFacenda]

Does that mean you haven't tested them yet? You can find the plugin IDs that this flake uses on the bottom of the plugin marketplace pages: plugins.jetbrains.com/plugin/25044-stonecutter-dev -> "Plugin ID"

Thanks, I missed that, I tried grepping the plugin source but found nothing.

I will think about the best way to implement the rest, I will put myself as a maintainer for the plugins I use.

Also, most of the overrides right now are just for running autoPatchelfHook and fixing permissions on binaries. If you don't think that this adds much overhead we could put this as default (there are probably a lot of plugins that needs autoPatchelfHook).

[MattSturgeon]

most of the overrides right now are just for running autoPatchelfHook and fixing permissions on binaries.

This sounds like something that could be applied across all plugins without needing plugin-specific overrides?

[theCapypara]

I agree, if there are some generally applicable things we can just do them to all plugins, always. We just need to be careful with the single-jar file plugins, not sure how autoPatchelfHook likes it if src is just a single file.

I think as for how to implement per-plugin overrides, it could be useful for you to wait for #172 to be done. It might be useful to wait for pluginsForIde and then in this PR to change pluginsForIde to return something like this:

{
    plugin-id = {
        src = plugin-drv; # The unmodified plugin
        override = special-plugin; # The content of special-plugins.nix for this plugin ID or null.
    };
    plugin2-id = ...;
}

buildIdeWithPlugins would then take this structure and build the final plugins from it. Alternatively buildIdeWithPlugins still can just take a list of plugin IDs, it then just calls pluginsForIde internally.
To disable the override one could just set override to null and one can also supply custom overrides. We could also just return the final drv from pluginsForIde and let users pull out the src manually to remove the overrides and get the "raw" plugin, but I think this is friendlier.

Examples (pseudo code):

# Simple like before
buildIdeWithPlugins pkgs "idea" [ "IdeaVIM" ]

# Long form
buildIdeWithPlugins pkgs "idea" (pluginsForIde "idea" [ "IdeaVIM" ])

# Disabling overrides
let
   plugins = lib.recursiveUpdate (pluginsForIde "idea" [ "IdeaVIM" ]) { IdeaVIM = { override = null; }; };
in
buildIdeWithPlugins pkgs "idea" plugins

Or something similar to that :)

If you both think that could be a good approach we could merge #172 into an intermediate branch instead of main so we don't introduce that function yet and then do breaking changes to it so shortly afterwards.

[MattSturgeon]

this PR to change pluginsForIde to return something like this:

{
    plugin-id = {
        src = plugin-drv; # The unmodified plugin
        override = special-plugin; # The content of special-plugins.nix for this plugin ID or null.
    };
    plugin2-id = ...;
}

I like the proposed direction, but I think we should avoid pluginsForIde returning complex structures.

If it returns a simple list or a flat attrset, then it is easy for end-users to integrate with other tooling (such as pkgs.jetbrains.plugins.addPlugins) themselves, by passing the list (or attrValues) directly.

---

I suspect we could still achieve the goal by introducing an "overridePlugins" function which mapAttrs a plugins attrset, or a "getOverridesForPlugins" function, which genAttrs a list of plugin IDs.

As for making this configurable, I wonder if that is best achieved by either: exposing these functions to end users, so they can run them themselves and inject logic in-between; or by adding With {settings} base-functions that can be explicitly configured to behave in a specific way.

E.g.,

buildPluginsForIdeWith
  {
    applyPluginOverrides = false;
  }
  pkgs
  "idea"
  [ ];

buildPluginsForIdeWith
  {
    dontOverride = [ "IdeaVIM" ];
    extraOverrides = {
      "com.intellij.plugins.watcher" = plugin: plugin.overrideAttrs (
        finalAttrs: prevAttrs: {
          # ...
        }
      );
    };
  }
  pkgs
  "idea"
  [ ];

Not sure this is the perfect solution, just throwing ideas out there. 😁

[theCapypara]

I like the With {settings} pattern! I think that hits a good middle-ground of the possible solutions.
In that case we wouldn't change pluginsForIde here and I'd merge #172 to main.

[SamueleFacenda]

Ok, I'll update the code soon. I'll try to integrate some version handling to default overrides, from my experience with the github copilot override it make sense to have different overrides for different versions, but it would add a lot of complexity. Maybe it's better to keep only one override per plugin and let the users apply their own overrides for older versions, what do you think?

[theCapypara]

@SamueleFacenda I'll mark this as a draft while still in progress, please undraft when ready to review, and let me know if I can help in any way :)

[SamueleFacenda]

Ok. Sorry, I'm very busy with university exams in this period.

[SamueleFacenda]

@theCapypara the PR is almost ready. But with the latest nixpkgs update I found out that the copilot patch doesn't always work (e.g. works for clion 2025.3.2 but not for clion 2025.3.1.1, same plugin version), so I tried different approaches.
The easiest (and way cleaner solution) requires that node is in PATH when the IDE is running, but I found impossible to do this.
I also looked for patching the function that finds the executable in the jar but it's not possible for what I saw.

[theCapypara]

Hm, I'm sorry but I can't help much with that. Plugins can't alter the PATH afaik, you need to patch how the plugin searches for the binary and provide a store path (probably).
Copilot works fine for me, but I don't use the chat features, just the auto-complete.

I also don't understand why Microsoft feels the need to shove NodeJS into everything.

[MattSturgeon]

I had a quick look over the diff. Didn't look too closely.

[MattSturgeon]

This looks redundant. We're using stdenv already, not stdenvNoCC. Isn't libc available by default?

[SamueleFacenda]

I'm checking, this was included in the nixpkgs patches.

[SamueleFacenda]

It's actually needed, without it plugins like PythonCore fails to build because the autoPatcheldHook cannot find that libraries:

> auto-patchelf: 2 dependencies could not be satisfied
> error: auto-patchelf could not satisfy dependency libstdc++.so.6 wanted by /nix/store/m70njsq0l1fmkhisfwf83cmr0x8mzw98-PythonCore-253.30387.90/helpers/pydev/pydevd_attach_to_process/attach_linux_amd64.so
> error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/m70njsq0l1fmkhisfwf83cmr0x8mzw98-PythonCore-253.30387.90/helpers/pydev/pydevd_attach_to_process/attach_linux_amd64.so```