Yes, now, everything works. I can compile not only pandoc and qtah-generator (both from nixpkgs and from git via stack2nix), but my projects that failed to build before these commits.

@angerman

Thanks @mpickering for the ping! Right, this looks a bit more sophisticated than the hack I have in #37254. #37598 also does some improvements in this area.

In general--and what @shlevy also mentioned--we likely really want to encode the build-type from the cabal file in the generated .nix expression by cabal2nix. That way we would know beforehand if we want to depend on the simple or a custom setup.hs.

I haven't looked into that much, as an alternative haskell infra[1,2,3,4], does expose the build-type, and I've been using that primarily for the last few weeks.

--
[1]: https://github.com/angerman/Cabal2Nix
[2]: https://github.com/angerman/haskell.nix
[3]: https://github.com/angerman/hackage.nix
[4]: https://github.com/angerman/stackage.nix

@Ericson2314

@angerman

we likely really want to encode the build-type from the cabal file in the generated .nix expression by cabal2nix. That way we would know beforehand if we want to depend on the simple or a custom setup.hs

Yes, this will allow us to reuse Setups for standard build types, as what I don’t like currently is that the number of derivations built increased twofold and the output of nix-build looks intimidating. But this optimisation is hardly critical and we can do it later.

@kirelagin I like this :). I, like @angerman, want more more derivations, but as #39646 shows @peti isn't yet on board either. This should be less controversial, yet also be a path towards more derivations as the same helpers can be reused in e.g. per-component derivations. So yeah, I think this is a net improvement while leaving all the doors open. Nice work :).

@peti what do you say to this? I'll happily volunteer to fix the eval errors if @kirelagin doesn't beat me to it, but we need approval on the concept.

So what’s the plan?
If there are other ideas how to fix #39646 I’d happily look into them as well.

#40642 (reverted and now #40996) will fix. But I still like this more so hope we can do both. I view the generic-builder parts of the that PR as an incremental step towards this :).

#40996 has landed in master.

What is the status of this pull request?

There is interesting stuff here but I tht the proximate issue is fixed?

There is interesting stuff here but I tht the proximate issue is fixed?

I guess this can be closed then.

If anyone is looking for something that takes the path of turning more things into separate derivations, haskell.nix makes a lot of strides in this area.