<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 September 2016 at 19:53, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</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-"><br>
</span>Well, if the "snapshot" config is put in specific file, there's no<br>
reason why Cabal couldn't be taught to also read configuration from that<br>
file.  But if cabal-install wants it to be in "pkg description format"<br>
and Stack wants it to be in YAML I'm not sure how you are going to get<br>
the projects to agree on a shared format.  Snapshot config is put<br>
in cabal.project.freeze, which has the virtue of having the *same*<br>
format of cabal.project.</blockquote><div><br></div><div>How about cabal-install using the YAML format as hpack has proven that it works very well for expressing the existing .cabal files? YAML is simple, flexible and open, used across many tools so the knowledge of format is more widely sharable which has its advantages. Are there reasons to keep using the cabal format other than the legacy reasons and the pain of asking everyone to move to another format? </div><div><br></div><div>In the short run it is tempting to keep using .cabal since we do not have to manage a painful disruptive change. But that may not be so in the long run. Open technologies usually win in the long run as against the closed ones. Keeping aside the legacy knowledge advantage, we can objectively evaluate if .cabal is better than YAML or vice versa. </div><div><br></div><div>Inputs from original stack authors might also be useful on why they chose YAML over .cabal. I guess it might be similar to the reasons why someone wrote hpack to generate .cabal from YAML. Also they were starting fresh and so did not have to manage a disruptive change. But I fear if they will be willing to go for a closed format against an open format now even if some of the problems of the format are addressed. Maintaining a closed format perennially is also an issue unless it is very well thought out and does not require any changes.</div><div><br></div><div>-harendra</div></div><br></div></div>