Also, is there a reason this isn't buildInputs? I don't see why these inputs should be propagated...

I added them as propagated because farge needs these programs on path at runtime, and my impression of the difference is that buildInputs doesn't do this. Maybe I misunderstand the difference?

I think the main difference between propagatedBuildInputs and buildInputs is that: If a derivation A has a derivation B in its buildInputs, and derivation B has some derivations C, D, E in its propagatedBuildInputs, then A can see B, C, D and E in its PATH variable at build-time (and therefore A can, for example, save the path to C, D and E and execute them later at run-time). If C, D, and E are in the buildInputs (instead of propagatedBuildInputs) of B, then A only has B in its PATH at run-time. I hope someone corrects me if I'm wrong 🙃

But, I'm fairly certain that Nix doesn't "sandbox" any executables by default. What I mean is that the environment in which farge runs is the same as the environment from which it is executed, so PATH isn't changed by Nix, and farge can't find its buildInputs at run-time. But, this can be fixed easily, using the makeWrapper and wrapProgram shell functions from stdenv. I always use ripgrep to find out real-world examples of how to use NIx functions, and it seems you can just do something like this: wrapProgram $out/bin/farge --prefix PATH : ${stdenv.lib.makeBinPath buildInputs} (in postInstall for example) to make all buildInputs visible to farge via the PATH variable at run-time.

Now, I wonder how you got the packages available at run-time, though. Could it be that you already have wl-clipboard, slurp and grim installed in your user environment, maybe? Or ran farge from nix-shell? If not, I have probably misunderstood something.

@laikq You're very much on point with your explanation, nice!