[Suggestion]: Flake alternative to `download_or_build_binary()`

[aSapien]

Which fff frontend(s)?

Neovim plugin (fff.nvim)

What problem are you trying to solve?

In a Nix-flake based installation, I would like Nix to build and bundle the needed binaries, so that the Neovim plugin can use the respective /nix/store/.. path (or nix-managed $PATH) instead of relying on the plugin manager's "build" directive.

Proposed solution

Expose fff-search in the flake.nix packages, so that the installation becomes deterministic and external to the neovim plugins architecture.

[gustav-fff]

[triage-bot] QUESTION:

Flake already exposes the Neovim plugin with the dynamic library prebuilt — no download_or_build_binary() needed. See flake.nix:122-128 (packages.fff-nvim) which calls pkgs.vimUtils.buildVimPlugin and bakes libfff_nvim.{so,dylib} into the plugin via postPatch = copy-dynamic-library (flake.nix:101-110).

Usage:

# in your flake inputs
fff-nvim.url = "github:dmtrKovalenko/fff";

# then
programs.neovim.plugins = [ inputs.fff-nvim.packages.${system}.fff-nvim ];

fff-search is a separate Rust crate (CLI/library, not used by the Neovim plugin). The plugin loads libfff_nvim via FFI, which packages.fff-nvim already bundles. If you specifically need a fff-search binary in $PATH, open a separate request and clarify the use case.

Honk-Honk 🪿

[dmtrKovalenko]

@aSapien what are you looking for? As gustav mentioned above we already have nix flake for neovim and mcp

[aSapien]

@dmtrKovalenko the solution suggested by gustav is actually workable, but subjectively not ergonomic enough.

In the suggested solution, I must make a choice. Either:

1. Manage the Neovim plugin entirely with Nix and get the needed dynamic libraries bundled
2. Use a plugin manager and have it download of the dynamic libs.

However, I manage my plugins specs using a plugin manager i.e. lazy.nvim, but at the same time managing all my binaries/libraries/environment using nixos/nix-darwin/home-manager.

I think the best solution for my use-case would either be a configurable lua variable opts.fff_dylib_dir which I would be able to set to the Nix output of the dylibs, or a binary (fff-search?) which I could set on $PATH and have the plugin use it instead of the dylibs.

In (arguably) sophisticated flakes where multiple heterogeneous machines are provisioned, the ability to separate configuration from dependencies goes a long way.

Thanks for the great plugin attention to this issue!

[dmtrKovalenko]

I don't really understand. You can just run nix build on lazy hook instead of download_and_build_binary and it will work exactly same

Isn't it?

[aSapien]

You can just run nix build on lazy hook instead of download_and_build_binary and it will work exactly same

@dmtrKovalenko I'm not sure that I'm following you correctly, but if you're referring something like this

{
  "dmtrKovalenko/fff.nvim",
  lazy = false,
  build = function()
    os.execute("nix build github:dmtrKovalenko/fff#default")
  end,
},

then it's not a good solution either.

This will build the package and put a symlink to the shared libs in ./result/lib/libfff_* relative to the build directory.

While this may work (with some adjustments), after some time the Nix Store garbage collection will remove these paths, since the store address is not referenced by the Nix profile.

[dmtrKovalenko]

I am sorry I have hard times understanding what exactly you need

build = "nix run .#release",

this seem to be working for people using nix to build fff - if you have any specific suggestion feel free to open a PR