package.yaml and *.cabal divergence solutions

[BebeSparkelSparkel]

Following up #230, I received some good suggestions https://discourse.haskell.org/t/ensure-that-package-yaml-and-cabal-are-synchronized-in-a-github-workflow/9950

If using hpack to generate .cabal from package.yaml — version-control only the package.yaml, and git-ignore the generated .cabal output.

Don’t use package.yaml. It complicates workflows and has no major benefits.

These in my opinion are the best options. Any thoughts?

[L0neGamer]

For libraries I feel the package.yaml isn't useful as you can't put library boundaries (or it's not standard to because of stack). Moving over to .cabal only would be a way forward, in my opinion.

[BebeSparkelSparkel]

https://tech.fpcomplete.com/blog/storing-generated-cabal-files/ recommends both, so I think we will have to keep it how it is.

[BebeSparkelSparkel]

@L0neGamer I have come to appreciate your opinion on this.
@gregwebs What do you think about removing the package.yaml files?

[gregwebs]

It's not a bit deal either way. I think the motivation would be if you wanted to create a tool to do something like bump multiple packages in this repo at once then the yaml format is really easy to work with.

[BebeSparkelSparkel]

What convinced me me is the tool cabal-gild that allows for the utilities of hpack without redundant sources.