DeterminateSystems / zero-to-nix

Zero to Nix is your guide to learning Nix and flakes. Created by Determinate Systems.

Home Page:https://zero-to-nix.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Issue with page `src/pages/start/4.nix-build.mdx`

gitbm opened this issue · comments

commented

When following the instruction for a Scala based package build I got a confusing error about a hash mismatch.

nix build
error: hash mismatch in fixed-output derivation '/nix/store/1f8f1lj7ag8rjjl6p95k70bfb4h75h3d-zero-to-nix-scala-sbt-dependencies.tar.zst.drv':
         specified: sha256-rFh3dTcK65/sFOy2mQI6HxK+VQdzn3XvBNaVksSvP0U=
            got:    sha256-eOSvpVOMjIO+oUErei4NGj9xMKknhkFe6+NrUui+hm8=
error: 1 dependencies of derivation '/nix/store/idrnz1qng1nq1xdxmr8rb0ri2yz74jrc-extract-dependencies.drv' failed to build
error: 1 dependencies of derivation '/nix/store/4myv9crcxfnn8z2gzff5sbzgis4mzslq-zero-to-nix-scala-0.1.0.drv' failed to build

I tried a few different things that didn't work before looking at the flake.nix file. Hardcoded in there is a variable called depsSha256. I have no idea why such a thing is in there with a hardcoded value and even less idea why it doesn't work but I tried substituting this value with the one from the error message and it worked.
My first impression of Nix was that it was a rock solid system based on repeatable builds but now it seems fragile, dependent on magic values and requiring too much knowledge of intricate details. Perhaps this problem is limited to the way the scala/sbt derivation has been setup but not a good experience when you are going from zero to nix

PR #273 fixes this.

@gitbm In this case, the Scala dependency hash was indeed incorrect and that's a bug. Thanks for reporting! Regarding "magic," well, I guess it depends on your definition. Nix strives for correctness and for some, like myself, that is its magic. It's quite common in Nix to provide dependency hashes, particularly when you're using tools (like sbt but also many others) that fetch things from the Internet. To ensure reproducibility, you need to make sure that those tools fetch the same thing every time, and dependency hashes are a highly efficient way to ensure precisely that reproducibility that you mention. If Nix simply assumed that build tools do "the right thing" then people could no longer trust their dependency trees to not contain random things pulled in from the Internet and the value—and standing—of Nix would decline precipitously.

From a UX perspective this could be seen as suboptimal because it's a bit weird to have an opaque string in your config files and checked into version control. But Nix has to work this way in order to provide the guarantees that it does.