It is not “fail fast on errors”, it is that IFD doesn’t suite flake tooling well.
As soon as a flakes output uses IFD and produces any output which’s target system isn’t the one that evaluates the expression it breaks.
This is somethings that can be fixed in nix, as shown in the PR linked from the second link.
I know that I am relatively alone with my strict approach to IFD, though lets be honest…
My setting of strictly forbidding IFD, does not impact me in daily use, unless I touch haskell.
In other situations it even uncovered bugs that I would probably not have seen otherwise. Most recent one was when I inherit
ted something that I shouldn’t inherit because of a typo.
I understand how people do not want to have nix files “poluting” their clean projects. I understand the demand for a single source of truth.
So: convert the lockfiles into JSON in repo. No need for IFD anymore. Use projects like the cabal hashes in JSON format in the nix-community org. Or even fix the haskell tooling to use a lockfile and hashing format we can actually use directly.
What annoys me most:
There is no maintained alternative, that would allow to not use IFD easily. Someone suggested to use haskell.nix already, though that again seems to include an hour long ceremony to regenerate the haskell lock files on each change in the cabal file.
Damn, other ecosystems have a oneshot command one can use to pregenerate the files just in the repo, making it easy to use them in the “pregenerate” or “IFD” modes.
Just think abobut it… How easy could it be, if there was a oneshot command that generates a nix compatible lock file that just can be consumed from within nixpkgs, just passing it to a builder along the source.
I really hope that dream2nix will be there soon, and I wish, there would be more contributions to it rather than fractioning a single languages ecosystem even more.
I’m really thankful for contributions to any of the ecosystems, though I fail to see the value in creating yet another project, that just works the same than the previous ones.
Don’t get me wrong, I’m pretty sure there was a reason why @cdepillabout felt the need to implement yet another build tool for Haskell, and its probably valuable for that use case, but what makes that usecase not a good fit for the already existing tooling? Why hasn’t the existing tooling got adjusted to match that use case?
TL’DR: My biggest problem with IFD, it is just assumed in the haskell ecosystem. There is no easy way to opt out for those who do not want to use it. The reasons for their desire are not relevant. Perhaps its just because they want to use a hydra instance for CI…
PS: I am totally fine to avoid haskell until there are alternatives, still I will continue to ask the same question everytime a now tool pops up.