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

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

At the moment, cabal-install doesn't support hpack natively but if the project can be build with cabal-install, you can run hpack manually to produce the .cabal file and utilise dr-cabal after that :)

Hm thanks for that, could try out some of those ideas. Here's the github issue i opened for this: https://github.com/haskell/cabal/issues/8580

Would really love it if the Cabal documentation had this as its own, highly visible entry. I submitted a pull request to that end.

Sometimes cabal's output is confusing with regards to optimization levels: https://github.com/haskell/cabal/issues/6221

Direct link to changelog: https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.8.1.0.md

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

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).

I also prefer stack for development, but I use nix to deploy to production. This way, I can install ad-hoc system dependencies locally and play with them during development as well as enjoy the bits and pieces of Haskell ergonomics stack affords, and once I'm happy with what I have, I "nixify" those dependencies as part of the project nix configuration and send them to production without fear. I use IOHK's excellent haskell.nix infrastructure to nixify my stack-based Haskell project, which makes it trivial to maintain a nix configuration that's always in sync with my stack configuration.

And stuff like haskell.nix is supposed to let you configure things with stack or cabal or whatever tool you find most convenient, and let nix do the rest.

/u/ItsNotMineISwear mentioned haskell.nix, which does generate a Haskell package set based on either a stack.yaml file, or the Cabal solver. This would solve some of your problems, but then possibly introduce others.