Just trying this out in the nix repl (with a different hash, sha256-sCB418okyRpBoangSckLe5psFmvvcs7XsNFGveE0C7c=. Not sure why your hash didn’t work. EDIT: Oh, of course, it’s the storepath of bash being different.), I noticed something odd:
This derivation produced the following outputs:
out -> /nix/store/580kw5dz53x59in19ml4lmk2g8x66kad-test-fod-0.1.1
yet the actual store object that was created is named /nix/store/5npnpc3z35vzbc651rwgiphkzy4y3a6b-test-fod-0.1.1.
Make sure you’re not using an old outputHash. If you don’t update that after changing your derivation, Nix will just assume the derivation has the same output and yield that.
Exactly, there is a fixupPhase that “repairs” your #!/bin/bash
line. You can opt-out with dontFixup = true; option.
If you see majority of fetchers in nixpkgs repo dont use the standard
build phases. They have a custom builder script. That’s because
standard build phases preassume you are building a normal derivation
not a fixed output one.
FODs are fundamentally only supposed to be used for things that are very resistant to changes in dependencies or environment, like using curl to download a file from a URL. It isn’t supposed to matter which curl you use or whether some database of package dependencies changed something and a dependency resolution algorithm made a subtly difference choice. If you’re doing real computation or accessing complex databases inside a FOD, you’re probably doing it wrong. At least for the reason that those output hashes will break way too often. Including a nix store path in the output of a FOD is kind of the epitome of this problem, since they tend to change constantly, and is disallowed I think at least in part just to give people a push not to try to do this kind of thing.
I’m not sure of the exact reason you’re seeing this precise failure mode. Based on my observation, there might be some bug causing a miscalculation of the store path, so the derivation that gathers all the links together sees a non-existent store path. However, I do know that using FODs this way is discouraged, for good reason. FODs themselves might have been a bad idea, and we should have instead stuck with only a select set of builtin fetchers, but what is, is at this point.