
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

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
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 18th, 2021 at 20:52, Alexis Praga
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

Hi, Small feedback in case it’s useful: Switching from stack to cabal was painless with ghcup. I could not make it work without it (some dependencies failed to compile on Archlinux). Alexis Praga
Le 18 sept. 2021 à 21:07, coot@coot.me a écrit :
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
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 18th, 2021 at 20:52, Alexis Praga
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

Arch Linux has broken ghc installation as package maintener has some weird ideas… You have to install it via soirces and avoid Arch packagases like plague. Greetings, Branimir.
On 28.09.2021., at 10:00, Alexis Praga
wrote: Hi,
Small feedback in case it’s useful:
Switching from stack to cabal was painless with ghcup. I could not make it work without it (some dependencies failed to compile on Archlinux).
Alexis Praga
Le 18 sept. 2021 à 21:07, coot@coot.me a écrit :
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
Sent with ProtonMail https://protonmail.com/ Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, September 18th, 2021 at 20:52, Alexis Praga
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/ https://www.fpcomplete.com/haskell/tutorial/stack-script/
--
Alexis Praga
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

The only thing that was holding me back from dumping Archlinux packages was xmonad. It turns out it can easily be installed with: cabal install —lib xmonad xmonad-contrib Thanks, Alexis Praga
Le 28 sept. 2021 à 10:12, Branimir Maksimovic
a écrit : Arch Linux has broken ghc installation as package maintener has some weird ideas… You have to install it via soirces and avoid Arch packagases like plague.
Greetings, Branimir.
On 28.09.2021., at 10:00, Alexis Praga
wrote: Hi,
Small feedback in case it’s useful:
Switching from stack to cabal was painless with ghcup. I could not make it work without it (some dependencies failed to compile on Archlinux).
Alexis Praga
Le 18 sept. 2021 à 21:07, coot@coot.me a écrit :
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
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 18th, 2021 at 20:52, Alexis Praga
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
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Tue, Sep 28, 2021 at 11:34:42AM +0200, Alexis Praga wrote:
It turns out it can easily be installed with: cabal install —lib xmonad xmonad-contrib
If you need xmonad-contrib you most likely have your own xmonad configuration, in which case it's IMHO even simpler to define a cabal project for your xmonad configuration, which then depends on xmonad, xmonad-contrib or xmonad-extras (e.g https://github.com/dan-t/xmonad-config). This made it a lot easier for me to rebuild my xmonad configuration when updating anything on my system. Greetings, Daniel

On 28-09-21 14:02, Daniel Trstenjak wrote:
in which case it's IMHO even simpler to define a cabal project for your xmonad configuration, which then depends on xmonad, xmonad-contrib or xmonad-extras (e.g https://github.com/dan-t/xmonad-config).
I do the same and I think it is better. I just want to point out that sometimes you will miss the mod-q keybinding to recompile and test on the fly :^| -- Rubén. (pgp: 4EE9 28F7 932E F4AD)

If you use a build script (see the xmonad-testing repo for one that works
with cabal projects; it's tested because I use it myself) you can get mod-q
back.
On Thu, Sep 30, 2021 at 11:00 AM Ruben Astudillo
On 28-09-21 14:02, Daniel Trstenjak wrote:
in which case it's IMHO even simpler to define a cabal project for your xmonad configuration, which then depends on xmonad, xmonad-contrib or xmonad-extras (e.g https://github.com/dan-t/xmonad-config).
I do the same and I think it is better. I just want to point out that sometimes you will miss the mod-q keybinding to recompile and test on the fly :^|
-- Rubén. (pgp: 4EE9 28F7 932E F4AD) _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh allbery.b@gmail.com

Speaking about a build script, FreeBSD has one for xmonad (see below, located in /usr/local/share/examples/xmonad/build). 8<------------------------------------------------------------------------------ #!/bin/sh # must match "executable" line from xmonad-config.cabal EXE_NAME=xmonad-config # xmonad tells us how it want resulting executable to be named output_file=$1; shift CFG_DIR="$HOME/.xmonad" if [ ! -f "$HOME/.cabal/config" ]; then cabal new-update fi # build the config cd $CFG_DIR cabal new-configure --enable-optimization --enable-executable-stripping cabal new-build if [ "$output_file" != "" ]; then # move resulting binary where it was requested to reside res=`find $CFG_DIR/dist-newstyle -type f -perm +111 -name $EXE_NAME` if [ "$res" == "" ]; then return 1 fi # use "mv" to be able to replace a running executable mv -f "$res" "$output_file" cp "$output_file" "$res" fi 8<------------------------------------------------------------------------------
On 30-09-21 12:22, Brandon Allbery wrote:
If you use a build script (see the xmonad-testing repo for one that works with cabal projects; it's tested because I use it myself) you can get mod-q back.
Good reference! Thanks!
-- Rubén. (pgp: 4EE9 28F7 932E F4AD) _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Alexis Praga

Stack is broken in WSL1, but I can use an older cabal just fine. So now I work on the same projects with stack on my linux laptop and cabal on my Windows desktop.
-- Keith
Sent from my phone with K-9 Mail.
On 18 September 2021 18:52:24 UTC, Alexis Praga
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

I have the opposite problem, in a way. I use cabal-install on my personal computer because it is just much faster, mostly because it uses libraries installed system-wide. However, I use Stack on remote servers because it takes care of installing GHC for me… Personally I would prefer one solution a la `cargo`. Dominik
participants (8)
-
Alexis Praga
-
Brandon Allbery
-
Branimir Maksimovic
-
coot@coot.me
-
Daniel Trstenjak
-
Dominik Schrempf
-
Keith
-
Ruben Astudillo