When to use precompiled binaries in a nixpkgs derivation

I am a maintainer of the cargo-lambda derivation derivation alongside the maintainer of cargo-lambda. I am a nix novice and the other maintainer is newer to nix that I.

While working on a PR to update to the latest, the other maintainer asked why we don’t use the statically linked pre-compiled binaries. As a nix novice, I was simply pattern matching many other rust packages. After downloading the statically linked pre-compiled binaries and trying it on nixos everything appeared to work on my machine. Additionally, there appears to be a statically linked binary for all supported architectures except aarch64-darwin. For the purposes of this discussion, let’s assume that the other maintainer is willing to create one.

At this point there are two options, re-write the derivation to use the statically linked pre-compiled binaries or for dive in and figure out why the check phase is broken. Which brings to me to the question.

When, if ever, is it appropriate to use pre-compiled binaries instead of building from source? If I knew the answer to this question, I would have enough information to reach consensus and begin implementation. If I am asking the wrong questions, please correct me.

For additional context, this is where all of the discussion is happening.


@taylor1791 greetings !

My 2 cents, on what I have observed so far in nixpkgs ecosystem

  • building from source is preferred as you can think of nix as build system ( not package manager ) and nixpkgs and monolithic ecosystem

  • as an ecosystem, and not a package manger, you can do thing like change version of rust compiler, change version of llvm that rust uses and so on, and so you would expect that rust crates are all using/build with versions of libraries from nixpkgs

  • statically linked libraries build for other distributions may have assumptions on where files live in filesystem, but libraries from nixpkgs are most likely to have been patched/fixed to work with nix

  • there are sometimes reasons to package official binaries, even for opensource projects, the one i have to deal with is wkhtmltopdf, its a very large project, that has a lot of issues with packaging patched legacy dependencies ( with known security vulnerabilities ), for such case exists wkhtmltopdf-bin derivation that packages officially published binaries.

I hope this gives you some direction


On top of the excellent reply you’ve already received, there are also important trust issues with using pre-compiled binaries. In general, we have no guarantee that a binary from somebody else corresponds to the source code they claim it does, so it would be very easy to hide malware in such a binary. We should be aiming to eliminate binaries from Nixpkgs where we can, and certainly not adding more unnecessarily with the associated risks.

And, as you’ve identified, upstreams rarely make binaries available for all platforms we might be interested in having the package for. In Nixpkgs we support (to varying degrees) building for at least five operating systems and more than ten architectures, not to mention custom targets with optimised compiler flags, etc., but we’re not going to find binaries for all of those combinations.


is quite interesting, not only does static linking not benefit from upgraded and patched libraries managed by the system…

it can also be licensing issue too. I’d n ever thought about that…

There you go!