vimPlugins.go-nvim: add guihua-lua to dependencies

[PerchunPak]

Fixes #476883

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[PerchunPak]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 477519 --package vimPlugins.go-nvim --package vimPlugins.guihua-lua
Commit: 614237beca8d7d75db7ca413f9d1be42022353b0

---

x86_64-linux

✅ 2 packages built:

• vimPlugins.go-nvim
• vimPlugins.guihua-lua

---

aarch64-linux

✅ 2 packages built:

• vimPlugins.go-nvim
• vimPlugins.guihua-lua

---

x86_64-darwin

✅ 2 packages built:

• vimPlugins.go-nvim
• vimPlugins.guihua-lua

---

aarch64-darwin

✅ 2 packages built:

• vimPlugins.go-nvim
• vimPlugins.guihua-lua

[khaneliman]

Overall LGTM, minor nits on naming consistency with generated shared library and a comment fix.

Naming suggestion can be ignored, but think we should clarify the comment appropriately.

Generated file structure looks the same as mine in the plugin update.

I had this:

guihua-lua = super.guihua-lua.overrideAttrs {
    checkInputs = [ self.nvim-treesitter ];
    buildPhase = ''
      pushd lua/fzy
      make
      popd
    '';
    nvimSkipModules = [
      # NOTE: `.init` fails to find `init.lua`
      # We can require the `init.lua` fine though
      "fzy.fzy-lua-native"
    ];
  };

But, I don't mind having the dedicated drv for the lib itself.

[PerchunPak]

I liked it more how @khaneliman did it. Much better than separating it into its own derivation and having a lot of boilerplate

#477806 (comment)

[khaneliman]

LGTM, thanks for remembering the build hooks