[Haskell-cafe] [Haskell-community] technical thoughts on stack

[Patrick Pelletier]

On 9/14/16 7:46 PM, Harendra Kumar wrote:
> That's good news. I think the community will benefit from a healthy 
> competition among the tools. It is good to have choices in terms of 
> the front end but I would rather prefer a unified specification of 
> configuration. Currently with a stack workflow one has to deal with 
> two config files i.e. stack.yaml and project.cabal. There is no reason 
> why the stack and cabal configs cannot be unified.

To me, the stack.yaml and project.cabal file serve different purposes.  
The project.cabal specifies how to build a single package.  Even if you 
want to (try to) build that library in a very different build 
environment, everything in the project.cabal is still meaningful: source 
files, dependencies, license, how to run tests and benchmarks, etc.

The stack.yaml is about an entire build environment.  It is about things 
that have to (of necessity) be the same for all the packages that go 
into an executable: compiler version, snapshot, etc.

In other words, a single build environment can build many packages, and 
a single package can be built in many different environments. For 
example, in my directory structure for developing 
normalization-insensitive, I have three stack.yaml files:

stack-7.8.yaml
stack-7.10.yaml
stack-8.0.yaml

and I have three cabal files:

unicode-transforms/unicode-transforms.cabal
normalization-insensitive/normalization-insensitive.cabal
photos/photos.cabal

Each stack.yaml builds all three cabal projects.  And each cabal project 
can be built by any of the three stack.yaml files.  So, I see them as 
expressing very different concepts.

> Another point that I want to make is that I have found the cabal 
> config files hard to deal with. There are a number of annoying 
> problems with it and it lacks in reuse. That is the reason for tools 
> like hpack (https://github.com/sol/hpack) to be built to overcome 
> those problems. I think the problems that hpack solves should be 
> natively solved by cabal.

Yes, it would be nice if cabal-the-library could learn from hpack and 
solve some of the problems like redundancy.  I just wouldn't want to see 
fragmentation of the Haskell ecosystem.  (In other words, I want to be 
able to easily use any Haskell library as a dependency, even if the 
tools I am using are different than the tools the package author used.)

> I guess these problems are long pending and cabal did not evolve fast 
> enough. That could be one of the reasons for wrappers on top of cabal 
> or competing tools like stack getting created.

Well, hpack is addressing issues with the file format used by 
cabal-the-library, while stack is addressing issues with 
cabal-install-the-program.

> Are there any thoughts going towards a better config specification? 
> While we are at it it maybe good to have an extensible config which 
> can provide optional tool specific extensions.

Yes, that would be very nice.

--Patrick