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

[Duncan Coutts]

On Thu, 2016-09-15 at 08:16 +0530, 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.

As Patrick pointed out, your mypackage.cabal file covers a different
concept to either a stack.yml (or cabal-install's equivalents a
cabal.config or new cabal.project files).

This comes back to the separation of roles between the package author
and the package builder. Sometimes you are both the author and the
builder, but often enough you are building someone else's package, or
someone else is building your package. The person building the package
gets to decide things about the environment that the author does not
either know or choose (though they can describe the constraints on what
range of environments work).

So there has always been this separation between what you can write in
a .cabal file (author role), and what you can say on the command line
when you call cabal, or equivalently what you can write down in a
cabal.config (or new cabal.project) files, or stack's equivalent the
stack.yml file.

>  The concept of frozen snapshots is generic and useful enough to be
> incorporated as a common specification used by all tools.

The concept of package collections like stackage is certainly something
that can have a common spec.

More generally freezing involves keeping track of aspects of the
environment, and this is a bit more fuzzy because it depends how far
you want to go. One can just track versions of Haskell packages or go
as far as nix style package management where all aspects of the input
environment are captured.

> If there is a unified config then the same package can be used with
> stack or cabal, with hackage or stackage without any problems, choose
> what you prefer.

I don't foresee any particular problems here. They're using the same
.cabal files, and hopefully at some point both will be able to use the
same package collections. I don't think we'll unify the cabal.config
(or new cabal.project) and stack.yml files any time soon since these
deal with the project level builder role (as opposed to package level
author role) and the way the two tools deal with these things is a bit
different (and needs to be different so both tools can innovate).

> 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. 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.
> 
> 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. The plan is to allow "common" sections to be defined and then
included/merged into other sections. At the simplest this would be one
common section that is implicitly merged into all the components (ie
libs, exes etc) but in general would be multiple named sections that
are explicitly included. This change is dependent on a big rewrite of
the .cabal file parser that is underway.

Duncan