Different Binary Name?

[niksingh710]

In My flake I have two outputs, one default and other is nvim-lite where I have a different set of plugins.
Building any of them results in a binary name nvim that makes it impossible to have both at the same time.

How can I change the binary name of the specific output? Like for nvim-lite it to be nvim-lite?

[MattSturgeon]

Currently the standalone build doesn't modify the binary name.

The standalone derivation is here, and it joins together the (wrapped) neovim finalPackage, our custom nixvim-print-init pacckage, and the man-docs package. It also assumes the "main program" is nvim (used by lib.getExe and nix run etc).

I believe you could modify the nvim package to install a different name, either with an overlay/override or with another wrapper. But this won't affect the mainProgram used in the final joined package, or nixvim-print-init and man pages names.

[niksingh710]

Can you please share a snippet of how to achieve that?

[MattSturgeon]

I don't mess around with overlays often and I don't have a working example to hand.

Maybe look at unrelated nvim overlays for general examples. Also look into how the actual nvim derivation is built in nixpkgs to see what needs to be override. Probably mv $out/bin/nvim $out/bin/custom-nvim in postInstall would work?

Once you have an overriden nvim package, you can assign it to nixvim's package option

[MattSturgeon]

A simpler approach might be to create your standalone nixvim derivations as normal, but don't add these to your system packages list.

Instead you could create a symlink package that symlinks $out/bin/custom-name to ${lib.getExe nixvim-pkg}.

You'd have to manually symlink, set, or inherit any files, metadata, etc that you want to include/modify in your wrapper derivation, but this explicitness is definitely simpler overall.

E.g. using pkgs.runCommand:

custom-package = pkgs.runCommand
  # derivation name:
  "custom-pkg-name"
  # derivation args:
  {
    # you probably want to copy version & meta from your nixvim-pkg
    inherit (nixvim-pkg) version;

    # mainProgram should match your symlink's name though
    meta = nixvim-pkg.meta // { mainProgram = customName; };
  }
  # build script:
  ''
    mkdir -p $out/bin
    ln -s "${lib.getExe nixvim-pkg}" $out/bin/${customName}
  '';

Bear in mind, I haven't tested any of that and I'm typing it out on a phone keyboard...

You would obviously want to create your own mkRenamedNixvim function so that customName and nixvim-pkg could be fun parameters.

[niksingh710]

Trying to figure out a cleaner way to achieve this.
If I do, will put it here.

Maybe this is out of scope to nixvim but if nixvim flake can provide packages with different name having different set of configuration it will make the user to create different ide type env very easily on the go.

something like

packages = {
  # Lets you run `nix run .` to start nixvim
  default = nvim;
  lite = nixvim.custom.binary nvim "nvim-lite";
};

where nvim.custom.binary is a fn that accepts nvim as input and "nvim-lite" as binary name. where the lite one can have different set of extraArgs.

[MattSturgeon]

I think it's generally better to use the module system, rather than specialArgs.

If you want your config to vary between builds, just load your "common" module(s) along with your variant module(s).

To do that more cleanly, you can have one top-level common module that internally imports all your common options and config modules. And additional "top-level" modules for your variants.

The variants would enable/disable options you declared and/or override config from your common module.

nixvim derivations also come with the extendNixvim function, so you can build a tree of variants by starting with one "standard" nixvim build, then extending it with extra config or overrides.

If nixvim get support for baked in binary renaming, it'll likely be as a module option, not some additional mkNixvim function.