Hi Alexis,

There are several reasons:

* reproducible nix style local builds. By specifying hackage index one can build against the same set of packages locally and on CI.
* has access to whole hackage, though at times requires a bit of thought, most of the time it works just fine.
* `cabal.project` and `cabal.project.local`: the first corresponds to `stack.yaml`, the other does not have a counter part in stack. For example, this is very useful, when one wants to modify ghc options per package, e.g. adding or removing `-Werror` ghc option, or configuring a ghc plugin
* some options work better than in stack. One example is `--allow-newer`.
* one can experiment with backpack,

Cheers
Marcin

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 18th, 2021 at 20:52, Alexis Praga <alexis.praga@gmail.com> wrote:

Hi,

As an intermediate beginner, I've been back into Haskell for the last
months for a small project, using stack as the building tool.

Why stack ? A few years back, I learned that it was the "best" way to build
projects to avoid "cabal hell", which I understood at the time as
"managing dependencies with cabal is hard".

As such, I've use stack since and have been quite happy with it. The
only drawback is that building a project can be quite long.

This is usually not a problem, except for writing Haskell scripts using
shelly (for example), where the stack layout is a bit impractical for
fast-paced development. A solution is to use `runghc` or a script
interpreter [1].

However, I've seen some projects where cabal is used to build directly
instead of cabal, so it looks like the situation improved.

My question is this: in 2021, is there a reason to switch back to cabal ?

Thanks,

[1] https://www.fpcomplete.com/haskell/tutorial/stack-script/

--

Alexis Praga