lib.fakeHash exists to give the correct format of hash, but a useless value (I think it’s all zeros), so you could use that to start the trust-on-first-use loop. (You can also just change one character in it to something that’s clearly valid in that location.)
There are actually several forms of hash accepted by nix, so the “change to all zeros” only works if the format you started with was the right type for that (this one wasn’t).
I use the flake to lock the hashes of any Nix expression code, and I use nvfetcher to keep packages sources up to date. I dunno about best practice but it is definitely more convenient than doing this manually.
A hash is a binary string but since Nix files are plain text, using the hash as is would not be very convenient. For that reason a hash is typically represented as a number. To make the number shorter bases other than the common base-10 is used. Nix supports the following, demonstrated on SHA-256 hash with the numerical value 0:
Nix uses the length of the hash to determine the format. Since you replaced the base-64 hash with zeroes it was considered a base-64 format. In the encoding, each digit represents 6 bits so you need ⌈256/6⌉=43 characters. Since RFC 4648 wants the base-64 numbers to have lengths divisible by four, = is required as a padding. But you cannot really change it to 0, as that would give you 44*6=264 bits.
Right, fetchFromGitHub hashes the extracted source directory, while nix-prefetch-url hashes the downloaded file by default. As you discovered you will need to use --unpack when you want to use the hash for fetchzip or fetchFromGitHub, which often uses fetchzip internally.
You can also just set the sha256 attribute to an empty string and Nix will tell you the correct one.
This is base-32 encoded hash, which sha256 attribute supports just as well.
In this case, there is an update script so you can just run the following in your Nixpkgs checkout:
@toraritte Would be great if you could update that with the insights found here.
@jtojnar Maybe you can yourself add the bits you revealed here to the manual?
It feels like it would be multiple days of work to put all the correct information at the right level of detail into the correct places, but having it in one of the manuals at all would already be a good thing.
Besides lib.fakeHash, you can also leave the string empty (i.e. ""), and most functions in nixpkgs will then automatically substitute a hash. This takes the least typing, and doesn’t require a lib in scope if you’re working on something in a callPackage, so I tend to use that feature a lot when experimenting.
It does not work for fetchpatch, notably, but fetchFromGitHub does it.