I’m wondering why Nix would ever try to realise again a derivation that already failed.
If the derivation’s output are already valid, Nix do not realise a derivation a second time.
Otherwise, it would try to realise it again and again, while doing it more than once is useless (if the determinism assumptions hold).
I’m speaking here about the derivation’s builder failing. Not the required system/system features being unavailable, or the realisation being killed, etc.
I (think I) understand how Nix works and why there is this behaviour (the outputs path are not valid, period).
My question is more about if there is a good reason for that, and, if not, if it is possible to fix it.
Example
This command will ever fail and Nix will try to realise the derivation each time:
% nix-build -E 'derivation { name = "x"; builder = "y"; system = __currentSystem; }'
these derivations will be built:
/nix/store/7r40h4gj6rsaw6xnsq7vj128dpiawa94-x.drv
building '/nix/store/7r40h4gj6rsaw6xnsq7vj128dpiawa94-x.drv'...
while setting up the build environment: executing 'y': No such file or directory
builder for '/nix/store/7r40h4gj6rsaw6xnsq7vj128dpiawa94-x.drv' failed with exit code 1
error: build of '/nix/store/7r40h4gj6rsaw6xnsq7vj128dpiawa94-x.drv' failed
Use cases
- I sometimes put long tests in a derivation. If any of them fail, the builder eventually fails and the realisation fails. If I run again the same tests (same inputs, same derivation, same hash), it’s useless to waste CPU (and human) time.
- It could be useful to git bisect a broken package in nixpkgs: one could just run
git bisect run nix-build -A somepackage. If the inputs did not change and the build worked, we are just fine. If the inputs did not change but the build did not work, we are wasting time again. Think of it as a Nix-powered git-bisect<paths>argument.
Functional point of view
I guess we can see the failing derivation realisation as a bottom. But even in that case, Nix should not need to try evaluating the pure function twice.