[Haskell-cafe] [Haskell-community] technical thoughts on stack
code at funwithsoftware.org
Thu Sep 15 06:06:29 UTC 2016
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:
and I have three cabal files:
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
> 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.
More information about the Haskell-Cafe