Cabal VS haskell.nix

Also, there's already a cabal RFC to support toml: https://github.com/haskell/cabal/issues/7548

Cabal has a lot of dark corners once you stray from the happy path. Just checked and I'm currently subscribed to 37 threads on the issue tracker, and I'm not a maintainer. A lot of these are related to lesser-used features like cabal scripts, environment files and doctests (though I think all of these things would used more if they were more reliable), but there's also plenty of stupid stuff like: - https://github.com/haskell/cabal/issues/3313 - https://github.com/haskell/cabal/issues/8527 - https://github.com/haskell/cabal/issues/8391 - https://github.com/haskell/cabal/issues/7789 - https://github.com/haskell/cabal/issues/6888 - https://github.com/haskell/cabal/issues/6999 - https://github.com/haskell/cabal/issues/5271

Given that Mike Pilgrim (the Stack maintainer) is on Windows, and Cabal has issues on Windows, I think it might be easier to get Windows specific fixes merged in Stack.

The error message is not too helpful. This is the target of a long-standing ticket: https://github.com/haskell/cabal/issues/7993 Your help would be very welcome.

By the way, there are some open issues for the command to add a package in Cabal.

That's interesting. Could you could open a an issue about this? https://github.com/haskell/cabal/issues

I created this issue a few months ago: https://github.com/haskell/cabal/issues/8270

Reported this as a bug in cabal.

We definitely plan to have benchmarks once we start working on performance. We haven't started yet because there were more urgent tasks. For example: ensuring that the testsuite runs on CI with the JS backend (should be completed this week or the next), ensuring that the toolchain works properly (we're writing a tutorial and we've found new bugs, e.g. yesterday I've fixed the support for js-sources in Cabal https://github.com/haskell/cabal/pull/8636), adding TH support...

I'm not a great haskeller but I found haskell.nix better for Haskell projects, like the commenter on Discourse suggested. I've had a few issued regarding package versions with nixpkgs that haskell.nix solved.

FWIW, there's also libraries like haskell.nix that solve the caching problem.

I would try haskell.nix.

If you want to hurt your brain, check out haskell.nix. That's some good stuff right there ^^

The haskell.nix framework is good for this.

One cool thing is that this will enable GHC builds using ucrt instead of vscrt in the future. Concretely, together with NixOS/nixpkgs#171418 and its follow-up NixOS/nixpkgs#173498), this will e.g. allow haskell.nix to upgrade to a newer wine pin for TH cross compilation: https://github.com/input-output-hk/haskell.nix/blob/dd13e822529ae5342494969bce8a457522a60100/overlays/wine.nix

I've been using IOHK's alternative infrastructure for this reason. It has its quirks but I've been happier with it. Before that I think I was using developPackage from the nixpkgs haskell tooling which had some introspection ability. You may consider trying that out. But as I remember this will not abide by your version bounds.

There's a lot to like here. Alas, despite minimal dependencies, terminfo is somehow uniquely problematic in haskell.nix.

If you are somewhat comfortable with nix: https://github.com/input-output-hk/haskell.nix supports GHCJS 8.10.x (in particular 8.10.7).