feat(flake): expose nvimcom as a standalone package output

[Neurarian]

As mentioned in #615 , this PR would add an opt-in flake output for users who also want to manage nvimcom declaratively through Nix. For example, baked into a

rWrapper.override { packages = [...] }

set ahead of time. This is particularly useful for use with rix which doesn't allow installing R packages at runtime.

Depending on how the input is defined, it would be consumed via:

inputs.plugins-rNvim.packages.${pkgs.stdenv.hostPlatform.system}.nvimcom

Best,
Neurarian

[PMassicotte]

Thanks for adding this! Two small nits on the new packages.nvimcom derivation:

1. gcc and gnumake should go in nativeBuildInputs, not buildInputs. The packages.default build one commit earlier (#615) already does this correctly (nativeBuildInputs = [pkgs.gnumake pkgs.gcc]), and it matches nixpkgs convention, build-time tools belong in nativeBuildInputs so cross-compilation resolves them for the build platform rather than the host platform. Works fine natively (which is why it builds today), but would break under cross-compilation.

2. R doesn't need to be listed explicitly in buildInputs. pkgs.rPackages.buildRPackage (nixpkgs' generic-builder.nix) already unconditionally prepends R to buildInputs, so this entry is redundant.

Suggested fix:

packages.nvimcom = pkgs.rPackages.buildRPackage {
name = "nvimcom";
src = ./nvimcom;

nativeBuildInputs = with pkgs; [
gcc
gnumake
];
};

[Neurarian]

Thanks for the feedback! I should've checked upstream beforehand, sorry about that!
While I'm at it, I though to also restructure the packages part a bit neater and also make sure to add/bump the version numbers:

packages = let
  buildTools = with pkgs; [gnumake gcc];
in {
  # Optional: Add a package for R.nvim itself
  default = pkgs.vimUtils.buildVimPlugin {
    pname = "R.nvim";
    version = "1.0.0";
    src = ./.;
    nativeBuildInputs = buildTools;
    buildPhase = ''
      runHook preBuild
      make -C rnvimserver
      runHook postBuild
    '';
  };

  # Separate nvimcom R package
  nvimcom = pkgs.rPackages.buildRPackage {
    name = "nvimcom";
    version = "0.9.96";
    src = ./nvimcom;
    nativeBuildInputs = buildTools;
  };
};

I could also move the buildTools binding further up and also use it in the devshell definition, but that might make it a bit unclear.
I am unsure about the versioning cadence and the nvimcom package still reports v.0.9.96, so i've kept that. If the plugin and R package versioning should usually be in sync, I could also add this as a binding to the let-expression, so both derivations always report the same version number.
Let me know what you think and I'll update the PR.

[PMassicotte]

This looks good, thanks for the thorough follow-up!

The nativeBuildInputs fix and dropping the redundant R entry both look correct, and the shared buildTools binding is a nice small dedup.

Aslo, I do not think that we need to touch the devShell, its gcc/gnumake are there for interactive use rather than a build step, so keeping them inline separately from buildTools is fine as-is.

What do you think?

[PMassicotte]

Let me know when all is ready for merging!

[Neurarian]

I've squashed the fixup commit into the original for a cleaner history before merge. I'd say it's ready👍.

[PMassicotte]

Thank you very much!