Question: Haskell integration questions and freeform discussion

[ParetoOptimalDev]

Hi! I'm very interested in dream2nix as a current Haskell.nix user.

I have some issues with Haskell.nix currently, and was about to start trying to contribute fixes for it.

I learned about dream2nix and see that perhaps the best way forward for me could be adding cabal.project.freeze support to dream2nix.

Here are some rambling thoughts about why and questions you migth be able to help with. Ideally some of these things can serve as useful discussion points for future dream2nix Haskell integration as well.

So recently I had to workaround haskell.nix not supporting tarballs in mlabs-haskell/haskell-nix-extra-hackage#6 and this made me wonder how dream2nix currently supports local tarballs or would plan to support it without IFDs.

Reading the docs on the Haskell subsystem I see that cabal.project.freeze support is awaiting implementation.

Does this mean that implementing that allows us to use the cabal.project as a source of truth? It was my understanding (hopefully misunderstanding) that doing such a thing required IFD's the way that haskell.nix uses them.

If implementing support for cabal.project.freeze gets me cabal.project as a source of truth better than Haskell.nix currently provides that I'm very interested in helping out in the development of that. Especially if I get to avoid IFDs, hit more caches, and avoid building GHC's 😆

It seems kind of like cabal.project as source of truth and integrate better with the nixos.org infrastructure are fundamentally at odds.

cabal.project as source of truth makes Nix adoption for Haskell easiest.

Better integration with nix makes the exxperience of using Haskell easier.

[ParetoOptimalDev]

Also all nix integration currently has the downside of build-tools not working if you use cabal-v2 and it's the default. Here's a discussion you might want to weigh in on about it:

haskell/cabal#8434

[leungbk]

I learned about dream2nix and see that perhaps the best way forward for me could be adding cabal.project.freeze support to dream2nix.

I have a branch for cabal freeze at https://github.com/leungbk/dream2nix/tree/cabal-freeze (not yet usable). I haven't touched it in a while since I'm waiting for something like #257 to be merged.

[DavHau]

this made me wonder how dream2nix currently supports local tarballs or would plan to support it without IFDs.

We already do IFD to parse the .cabal file. We use cabal2json inside an IFD, then parse the JSON with nix. This does not necessarily mean that performance is going to be horrible. We try to minimize the number of IFD operations and their complexity.

Currently there is no support for tarballs as sources. Concerning IFD usage, if the tarball is part of one of your flake inputs, or contained in your specified source, using it as a package's source would not trigger an extra IFD. We can also fetch remote tarballs via FOD without triggering IFD.

The question is just, can we generate the derivation without looking inside the tarball, or does the tarball contain information that we need to inspect before starting the build. If the latter is the case, we would have to extract and parse files from the tarball, which would trigger another IFD.

I'm very interested in helping out in the development of that. Especially if I get to avoid IFDs, hit more caches, and avoid building GHC's laughing

As long as parsing .cabal files in pure nix is not possible, we have to use at least some IFD.
If you want to help the development, your efforts would be much appreciated.

Hitting the caches issue is unrelated to the IFD problem. If we manage to implement a mechanism that allows re-using the GHC's from nixpkgs instead of building our own ones, the caching issues should be improved a lot.

It seems kind of like cabal.project as source of truth and integrate better with the nixos.org infrastructure are fundamentally at odds.

I don't see why this would be the case. We don't have to integrate our whole mechanism with nixos.org. We just need to make sure that all the expensive to build components like compilers are maintained in nixpkgs for example.

[bezmuth]

As long as parsing .cabal files in pure nix is not possible, we have to use at least some IFD.
If you want to help the development, your efforts would be much appreciated.

Am I correct in thinking this is due to nix having no support built in for yaml parsing?

[DavHau]

Am I correct in thinking this is due to nix having no support built in for yaml parsing?

.cabal uses its own language. Yaml support would not help for that. But it would simplify parsing stack.yaml and stack.yaml.lock files.

[ParetoOptimalDev]

As long as parsing .cabal files in pure nix is not possible, we have to use at least some IFD.

Yesterday I remembered you saying this when I ran into NixOS/nix#4265 trying to write a github action for a Haskell flake that uses nixbuild.net.

I'm assuming that dream2nix probably builds for multiple platforms by default, but if that's not true maybe it's not affected here.

Not sure if you are familiar with this issue, but it seems like something you or I could definitely run into more.

Here are two solutions I found if that is the case:

• self-described hacky solution
• https://github.com/Plutonomicon/plutarch-plutus/blob/f8b7eb06184112ae2bebdec5a8156010141a05d5/flake.nix#L600

Also, I'm not sure if you find this discussion/issue useful or not. I'm fine with just closing if not.

I find it useful primarily to help me understand the future of Haskell/Nix in general and also to evaluate how much time I can justify potentially switching to dream2nix or contributing.

[DavHau]

Thanks for pointing this out. It seems like the nix flake check issue is nothing we can fix in dream2nix. We'll have to wait for the upstream fix. Anyways, we currently do not export checks via our builders and therefore won't run into these issues via our standard flake.

Though nix flake show can be fixed, as it only evaluates name and type attributes of the derivation and will be fine as long as those attributes are not computed via IFD.

The goal for dream2nix is to never run into issue with nix flake show. We can achieve this via some slight changes to the current haskell translators.

[DavHau]

Can this issue be closed?