better support Cabal-doctest

[shajra]

Hi!

I just created an issue against the Cabal-doctest project: ulidtko/cabal-doctest#57

It starts with the presumption that Cabal-doctest can be changed to be a little more Haskell.nix-friendly.

But I'd like to start an issue here to see if the converse is true. Can Haskell.nix be made more Cabal-doctest friendly?

As I wrote in the description for the other ticket, the problem is coming from components being built so hermetically separated from one another. When the Setup.hs runs for the doctest component, there are no library or executable components available in the LocalBuildInfo.

I still have yet to dig into the Haskell.nix side (I'd spent most of my time looking thus far looking at the Cabal-doctest code). But is there a way to still have separate derivations for each component, but maybe have components all show up in LocalBuildInfo?

[shajra]

I also posted a comment in Cabal too: haskell/cabal#4500 (comment)

On one hand, I think this can seem like it's just about doctests. But I think it's more about finding the right abstractions to make things like Haskell.nix more possible, while still retaining compatibility with other initiatives.

It's hard because I think the best solution involves the confluence of people from different projects, Haskell.nix included, which is why I'm linking issues between these three projects.

[shajra]

I've left a flurry of comments across the three projects now. But for Haskell.nix, I have one remaining question. I've really tried to do my best to ask Cabal if they'd be interested in better supporting building projects a component-a-time (Haskell.nix-style), but I can't guarantee that will happen, and even if it does, it won't happen any time soon.

I've now used both the native Nixpkgs Haskell infrastructure and Haskell.nix. I feel Haskell.nix is very good, and honestly, I would like for it to cover all cases. Rather than someone starting with Haskell.nix and then finding out later they need to switch to native Nixpkgs. And I think it would likely be a complete switch, because people would want a consistent dependency set across their whole build.

If we could figure out how to keep the dependency set from Haskell.nix, but still build everything all at once, even if really delegating to the native Nixpkgs infrastructure heavily, then I think we'd have solved not only this issue with doctests, but a whole slew of other complicated Setup.hs problems.

For not only doctests, but any package with a non-trivial Setup.hs, the best solution right now for Haskell.nix seems to be to patch in a Haskell.nix-friendly Setup.hs file, if you can figure out how to do that, which differs from project to project.

Building all components in one go just cleanly dances around this problem. I know this is kind of anathema to Haskell.nix's feature set, but I would never want this to be anything close to the default, just an escape hatch.

So I guess the questions I have are:

1. Is it possible?
2. Can I convince you it's worth it?

[michaelpj]

My understanding was that a key reason that Setup.hs is in a separate derivation is cross-compilation: the setup has to be compiled for the build arch, while the other modules are compiled for the host arch.

This just means that projects with non-trivial Setup.hs are hard to cross-compile, and haskell.nix surfaces that sooner.

Now, arguably this is a problem that cabal needs to confront in order to support cross-compilation better, but on the flip side it would be nice if haskell.nix supported the actually-existing Haskell ecosystem for people who don't currently care about cross-compilation.

[hamishmack]

I think cabal-doctest support works reasonably well now. See https://github.com/input-output-hk/haskell.nix/tree/master/test/cabal-doctests for an example.