Stack insists on building Cabal package

Question

I am working on a Haskell project using Stack. Recently, we started using the lens package which requires the Cabal package as a dependency, but we switched to lens-simple because building the Cabal package was too resource intensive for some older machines that we tested building the project on.

However, despite the fact that neither lens-simple nor any of our other packages have a dependency on the Cabal package, Stack continues to try and build it.

Is there anyway to get Stack to stop this? It makes the build process very long on most machines and impossible on weaker machines.

A list of the project's dependencies:

HUnit 1.6.0.0
QuickCheck 2.12.6.1
ansi-terminal 0.8.2
array 0.5.3.0
base 4.12.0.0
binary 0.8.6.0
bytestring 0.10.8.2
call-stack 0.1.0
clock 0.7.2
colour 2.3.4
containers 0.6.0.1
deepseq 1.4.4.0
directory 1.3.3.0
erf 2.0.0.0
filepath 1.4.2.1
ghc-boot-th 8.6.3
ghc-prim 0.5.3
hspec 2.6.1
hspec-core 2.6.1
hspec-discover 2.6.1
hspec-expectations 0.8.2
integer-gmp 1.0.2.0
lens-family 1.2.3
lens-family-core 1.2.3
lens-family-th 0.5.0.2
lens-simple 0.1.0.9
mtl 2.2.2
ncurses 0.2.16
netflak 0.1.0.0
pretty 1.1.3.6
primitive 0.6.4.0
quickcheck-io 0.2.0
random 1.1
rts 1.0
setenv 0.1.1.3
stm 2.5.0.0
template-haskell 2.14.0.0
text 1.2.3.1
tf-random 0.5
time 1.8.0.2
transformers 0.5.5.0
unbounded-delays 0.1.1.0
unix 2.7.2.2

I don't think lens has dependency of cabal. Why do you think so ? — Sibi
@Sibi I assume because lens has a custom setup, see the .cabal's custom-setup stanza. — Thomas M. DuBuisson

Michael Snoyman Michael Snoyman · Accepted Answer · 2019-03-17T05:13:22

My guess is that one of your dependencies using a custom setup stanza, where Stack needs to build the Setup.hs file against the Cabal library, thus the implicit dependency. We have a bit of a discussion going already for Stackage as to whether we should provide up to date versions of the Cabal library as we do today—and risk forcing people to build a heavy dependency—versus sticking to the version of Cabal that ships with GHC.

Anyway, you can work around this with a slightly convoluted approach where you create a custom snapshot that drops the Cabal library. It would look something like this:

# stack.yaml: point to the custom snapshot
resolver: snapshot.yaml

# snapshot.yaml: use the original snapshot and add a drop-packages
resolver: nightly-2019-03-17
name: drop-cabal
drop-packages:
- Cabal

Stack insists on building Cabal package

1 Answers