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