feat: add python3 options

[nekowinston]

Mostly lifted from home-manager.

Occured to me as a possible improvement since I had to resort to lib.mkForce to override cfg.build.before, when I tried a python extension some time ago.

[willruggiano]

Ironically the plugin you mention as impetus for this change was rewritten in pure lua :D

Regardless, this seems reasonable. When you are happy with it, take it out of draft and I can merge.

[willruggiano]

Here is a working spec for CopilotChat.nvim;

  copilot-chat = {
    src = sources."CopilotChat.nvim";
    config = true;
    dependencies = {
      copilot = {
        src = sources."copilot.lua";
        config = true;
      };
      tiktoken = {
        package = pkgs.rustPlatform.buildRustPackage rec {
          pname = "lua-tiktoken";
          version = "0.2.1";
          src = pkgs.fetchFromGitHub {
            owner = "gptlang";
            repo = "lua-tiktoken";
            rev = version;
            hash = "sha256-drSAVGHrdDdaWUEAfCE/2ZCI2nuffpbupO+TVWv/l4Y=";
          };
          cargoHash = "sha256-mMAUgq8Th6Vo3KCisDFnQn2knyL5qe0rAdw5OJUQ7ms=";
          buildFeatures = ["luajit"];
        };
      };
    };
  };

[nekowinston]

Ironically the plugin you mention as impetus for this change was rewritten in pure lua :D

I also noticed this while going back to my neovim.drv branch, what timing. 😅
Figured that there are still plenty of other plugins where it would make sense to have these options.

Regardless, this seems reasonable. When you are happy with it, take it out of draft and I can merge.

I already tried it on my old branch, and everything seems to work.
Not quite sold on the option naming yet? package and extraPython3Packages seemed fine to my 4am brain, extraPython3Packages seems comparatively verbose now. 🙃

Also, would it make sense to have a python.enable/node.enable, like NixOS/HM programs.neovim's withPython3/withNodeJs?

[willruggiano]

I already tried it on my old branch, and everything seems to work. Not quite sold on the option naming yet? package and extraPython3Packages seemed fine to my 4am brain, extraPython3Packages seems comparatively verbose now. 🙃

I think just extraPackages, since "python" is already part of submodule (python.extraPackages). Let's try to make this extensible, such that the plugin spec can have a python submodule too. I can't remember the extensibility utility functions, but maybe there is one there that will work for this case (extending a function). lib.mkExtensible or something along those lines.

Also, would it make sense to have a python.enable/node.enable, like NixOS/HM programs.neovim's withPython3/withNodeJs?

I'd rather not add options unless they demonstrably add value, and this does not seem like it does.

[nekowinston]

Let's try to make this extensible, such that the plugin spec can have a python submodule too. I can't remember the extensibility utility functions, but maybe there is one there that will work for this case (extending a function)

I don't think I understand what exactly you mean here. Do we need the full python submodule? 🤔
How would specifying different python interpreters on a per-plugin basis work?

I may be thinking about this wrongly, but couldn't we have a plugin spec pythonPackages that just acts like the plugin spec paths, collecting them from each plugin into neovim.build.before?

  copilotchat = {
    src = srcs.copilotchat;
    config = true;
    pythonPackages = ps: with ps; [prompt-toolkit python-dotenv requests tiktoken];
  };

I haven't had a reason to use lib.makeExtensible yet, it's totally possible I'm just missing the point. 😅

[willruggiano]

I may be thinking about this wrongly, but couldn't we have a plugin spec pythonPackages that just acts like the plugin spec paths, collecting them from each plugin into neovim.build.before?

  copilotchat = {

    src = srcs.copilotchat;

    config = true;

    pythonPackages = ps: with ps; [prompt-toolkit python-dotenv requests tiktoken];

  };

Yes this is exactly what I meant. Same as paths and env, which are both "global" and plugin specific.

Really what should happen is we should use propagatedBuildInputs to handle all of this, but that is neither here nor there.

[willruggiano]

fyi I probably won't have time to revisit this until middle/late next week

[nekowinston]

fyi I probably won't have time to revisit this until middle/late next week

That's alright, I'm in no rush to get this added for my own setup; I also didn't have time in the last few days.
I saw #6 and might give it a shot over the weekend, since you said that it would be the better solution.