Using binaries from PATH is the reasonable thing to do for upstream projects, so I don't think that we should patch in absolute paths. Just add the necessary programs to nativeBuildInputs.

Thanks a lot @orivej. I didn't do that because I didn't know which was better buildInputs vs nativeBuildInputs. I will update the commits as soon as possible

@orivej Fixed. Don't hesitate to ask for more changes

Why didn't you add perl too? Note that /usr/bin/env is fine and should be left as is.

@orivej, thanks a lot for your support and help
I hope to have done all right this time. I've also prograted htslib to samtools and bcftools.

Please review my changes.

samtools and bcftools install some python and perl scripts. We do not even depend on python, and I have not checked that perl scripts have all the necessary dependencies to run. This can be left as is until someone needs them.

That's perfect but I think that htslib has to be propagated to samtools and bcftools for using bgzip and tabix

Do you mean that users of samtools and bcftools also need bgzip and tabix in their PATH?

I think so because in other distros the htslib dependency is visible from PATH by default.
Which is your opinion?

Other distros have no other way. From a quick glance it does not seem that samtools need htslib binaries. (Even if they did, the proper solution is a program wrapper that adds htslib to the PATH of the wrapped program, not a propagation of htslib.)