How is used the sha256 of fetchFromGithub, exactly?

#1

I frequently copy and paste default.nix files around when creating custom packages, and it occurred to me several times already that I leave the sha256 of a previous default.nix.
In that case, when the sha256 is wrong bu correspond to some other existing package, I’ve noticed that nix-env behave strangely, pretending to install the new package but actually trying to install the previous one.
A good way to obtain the “correct” behavior (which is to fail to download the new package because the sha256 does not match the one of the default.nix) seems to do a nix-collect-garbage.

I therefore suspect that the sha256 is looked for in the /nix/store and “trusted” regardless of the actual package name, or something like that.

That’s very confusing the first few times this happen.
Can something be done about this ?

#2

If you leave the old sha256 in there, you’re explicitly telling Nix “this package produces output with this hash”, and if Nix already has output with that hash, it can skip building the derivation. So yes, it’s absolutely expected that if you leave the old hash in there, Nix will behave strangely.

The standard way of dealing with this is to replace the hash with a dummy hash, typically all zeroes. There’s even a convenience in nixpkgs for this, lib.fakeSha256 (or stdenv.lib.fakeSha256), along with variants for other hash types. Once you replace it with the dummy, you build and it will tell you of the hash mismatch, at which point you copy the correct hash into your derivation.

3 Likes
#3

Ah ok will try to remember about fakeSha256. Thank you!