search

snoyberg / mono-traversable

Type classes for mapping, folding, and traversing monomorphic containers
153 stars 63 forks source link

package.yaml and *.cabal divergence solutions #236

Open BebeSparkelSparkel opened 1 month ago

BebeSparkelSparkel commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

BebeSparkelSparkel commented 1 month ago

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

gregwebs commented 1 month ago

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 commented 1 month ago

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