When asked to build a project, stack will, rather than going to Hackage, look at the resolver field of stack.yaml. This arrangement is what the cabal-install documentation means by "Nix-style local builds". Version conflicts between dependencies are avoided by indexing the installed packages according to their versions (as well as other relevant configuration options), so that different projects can retrieve the dependency versions they need without stepping on each other's toes. Once a feasible build plan is found, the chosen version of the dependencies will be installed and indexed in a database somewhere in ~/.cabal. This set is drawn from Hackage as a whole - all packages and all versions, past and present. cabal file and use a dependency solver to figure out a set of packages and package versions that satisfy it. The key difference between them lies in how they address this goal:īy default, cabal-install will, when asked to build a project, look at the dependencies specified in its. Both tools make it possible to build Haskell projects whose sets of dependencies might conflict with each other within the confines of a single system. In particular, I will use cabal-install to avoid confusion with the Cabal library, which is common infrastructure used by both tools.īroadly speaking, we can say cabal-install and stack are frontends to Cabal. In what follows, I will refer to the two tools being compared as cabal-install and stack. There is a nice blog post explaining the difference: Why is Stack not Cabal? While Cabal has, in the intervening years since that post, evolved so as to overcome some of the issues discussed there, the discussion of the design goals and philosophy behind Stack remains relevant. Intero has a smooth experience when working with Stack.It provides an alternative (IMO, a better) way of writing cabal files using yaml file which is more widely used in the industry. Stack has built-in hpack support in it.
It also supports your own custom templates. Stack supports creating projects using templates.Using it along with -pedantic option is a deal-breaker for me. This will automatically rebuild if you change the local files present. Ability to do stack build -fast -file-watch.( Cabal also has a script feature, but fully ensuring reproducibility with it is not quite as straightforward.) Reproducible Haskell script: You can pinpoint version of a package and can get guarantee that it will always execute without any problem.Docker support (which is very convenient for deploying your Haskell applications).Stack even downloads GHC for you and keeps it in an isolated location.And there are things which Stack does which Cabal yet doesn't provide: Personally, I like Stack and would recommend every Haskell developers to use it. Note that there is also provision for using non stackage packages, so you are good to go even if a package isn't present in the stackage snapshot. Still, setting up a reproducible build configuration in which you know exactly what will be pulled from the repositories is more straightforward with Stack. Recent versions of Cabal also have measures in place to prevent conflict. That being so, any dependencies are known to build together, avoiding version conflict problems (which, back when they were commonplace in the Haskell experience, used to be known as "cabal hell"). Stack uses the curated stackage packages by default. In which cases should I use Stack instead of Cabal? What can Stack do that Cabal can't?
0 kommentar(er)
