-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
better support Cabal-doctest #388
Comments
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. |
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 For not only doctests, but any package with a non-trivial 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:
|
My understanding was that a key reason that This just means that projects with non-trivial 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 |
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. |
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 theLocalBuildInfo
.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
?The text was updated successfully, but these errors were encountered: