Add support for hpack (see #1679)

[sol]

No description provided.

[sol]

This adds minimal support for sol/hpack. The required modifications to hpack are not on Hackage yet. I would release a new version of hpack once we are done with code review and ready to merge.

[sol]

@mgsloan I'm not sure if that is the best place to call this. Any feedback?

[mgsloan]

I think this is the right place to call hpack, but this changes the meaning of getCabalFileName enough to warrant renaming it to findOrGenerateCabalFile. The new name isn't perfect (makes it sound like it'll always generate a cabal file if it's missing), however, this is better because it lets the reader know it may perform file system mutations (not merely a "get").

[sol]

Ok, makes sense. I'll change that some time soon (may have to wait until next weekend).

[mgsloan]

Awesome, thanks for working on this! Sorry for letting it languish, I got busy!

In order for package dirtiness to work properly, we need to only write to the cabal file when the hpack file is changed. Maybe rely on modification timestamps and generate a new cabal file only when the hpack is changed?

[phadej]

@mgsloan AFAIK Hpack.hpack doesn't touch .cabal file (reads but not writes) if nothing changed. That behaviour might need a comment though.

[phadej]

similar change is needed for stack-7.8.yaml

[sol]

Ok, noted.

[sol]

@mgsloan @phadej Yes, exactly, hpack generates the new cabal file and only writes it to disk if it changed. (see https://github.com/sol/hpack/blob/98110f843e6c981eb3764582295b1926cce198ca/src/Hpack.hs#L66)

[mgsloan]

Cool, once the updated hpack is released to hackage, and the comments are addressed, I'd be ready to merge this as an experimental feature.

[sol]

@mgsloan I addressed all the open points and released a new version of hpack to Hackage. From my perspective this is good to go now.

[mgsloan]

LGTM, thanks!