I'm not sure if this wrapping is done correctly. For instance, does the metadata propagate properly to the wrapped package?

These are micro-optimization that hurt maintainability and probably do not even pay of:

$ cd ~/go/src/github.com/dop251/diskrsync/diskrsync
$ time go build .
go build .  0.36s user 0.09s system 138% cpu 0.326 total

Your runCommand creates a separate derivation which probably takes longer if sandboxing is enabled then recompiling diskrsync

Ok! In that case, is preFixup wrapping in some way better than just adding openssh to propagatedBuildInputs? In my opinion, propagatedBuildInputs is easier to understand and maintain, but is it worse in some sense in this case?

It would only propagate in the context of a build or in a nix-shell, not if someone installs the package. Therefore a wrapper is the way to go.

Ok, thanks for the explanation. I'll make the suggested fix.

Well this is weird.. I tried prePatch phase but ls $out gives:

drwxr-xr-x 3 nixbld nixbld 4096 Mar 28 18:55 share

So there is no $out/bin, so I have no idea where .../bin/diskrsync should be located at this point of the build process...

Ah, the executable is in $bin/bin/diskrsync not in $out/bin/diskrsync. Always learning something.

Ok, made the fix. Good to merge now?