Stack's origins

Stack's origins

From a Reddit discussion on the 24 June 2015 article by Mathieu Boespflug "Why is stack not cabal?":

It started out with a Makefile a client was using to build multiple packages at once, and for our own projects, an internal Haskell script called fpbuild that would know how to unregister and upgrade packages properly when we updated. That was used for a couple years at FPCo. Then it became a Haskell project based on Shake that knew better how to read cabal files and figure out incremental building dependencies. Then we had a bunch of code in a number of projects for dealing with packages, using, modifying or replacing the Cabal library, with newer, more efficient data types and a coherent logging story among other things. Then we had all these tools lying around, so we re-implemented or merged them into the stack library, then made an executable which focused all our goals into one place.

With regards to cabal-install, almost every feature is implemented differently, with different libraries and/or different places to put or get things, and with our own types for packages, package names, versions, etc. it uses modern libraries and extensions. See the library. In all, a fork of cabal-install wouldn't look anything like cabal-install, source-wise or behaviour-wise, it'd have to have a new name (e.g. "stack" ;-) and would be a waste of time trying to "upgrade" instead of just starting from what we wanted to achieve and implementing it. The motivation was never “let's do this differently from cabal-install”, but rather “let's look at the user workflow (for newbies and big business projects) from scratch and then make a tool that fits it.” Stack is a few years' worth of commercial and newbie client tooling experience and feedback packed into one tool.