<div dir="ltr">While I agree that stack.yaml is a frozen config, we do not necessarily need a separate config file or a separate format for that. My main point was a that a new user will have to understand two more languages (YAML/cabal) in addition to Haskell. We can have the config spread in multiple files, but they should look like an extension of the same thing rather than disparate things.<div><br></div><div>The stack snapshot config can be seen as a higher level concept of the pvp-bounds in the cabal file. While pvp-bounds specifies a whole range, the snapshot is a point in that space. It can also be seen as a more general version of the "tested-with" field in the cabal file. We can instead say - tested-with these snapshots (or set of versions). Instead of using stack-7.8.yaml, stack-8.0.yaml manually, the build tool itself can list which snapshot configs that are available and you can choose which one you want to build. The config could be tool agnostic.</div><div><br></div><div>-harendra</div><div class="gmail_extra"><br><div class="gmail_quote">On 15 September 2016 at 11:36, Patrick Pelletier <span dir="ltr"><<a href="mailto:code@funwithsoftware.org" target="_blank">code@funwithsoftware.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 9/14/16 7:46 PM, Harendra Kumar wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
stack-7.8.yaml<br>
stack-7.10.yaml<br>
stack-8.0.yaml<br>
<br>
and I have three cabal files:<br>
<br>
unicode-transforms/unicode-tra<wbr>nsforms.cabal<br>
normalization-insensitive/norm<wbr>alization-insensitive.cabal<br>
photos/photos.cabal<br>
<br>
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.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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 (<a href="https://github.com/sol/hpack" rel="noreferrer" target="_blank">https://github.com/sol/hpack</a>) to be built to overcome those problems. I think the problems that hpack solves should be natively solved by cabal.<br>
</blockquote>
<br></span>
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.)<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
Well, hpack is addressing issues with the file format used by cabal-the-library, while stack is addressing issues with cabal-install-the-program.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
Yes, that would be very nice.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
--Patrick<br>
<br>
</font></span></blockquote></div><br></div></div>