Have stack use hpack as a library, and automatically add version bounds?

[mgsloan]

The overall idea is to have stack detect hpack files and automatically generate cabal files when the hpack files change. I'm not sure if everyone will be on board with the idea, but it seems like a good idea to me, lets discuss!

In commercialhaskell/stack#1568 , I lay out an approach to having multiple stack configurations inform wide version bounds for dependencies. One reason that I'm keen on hpack is that the stage where .cabal files are generated would be a great time to insert these version constraints.

[soenkehahn]

I think this is a great idea. hpack already exposes a library, not sure if that contains everything that would be needed for implementing that in stack.

[sol]

@mgsloan This is definitely something I want to support. zalora/tinc already does this, but tinc is experimental and stack has a much bigger momentum. So adding this functionality to stack would benefit a much wider audience.

The bulk of the work would be in stack, I would assume. But if there are any changes required to hpack to make this happen, I'm happy to discuss and accept PRs.

[mgsloan]

Cool! The main tricky part of the integration is trying to minimize the frequency of running hpack / writing new cabal files (by paying attention to file modification times, etc). I probably won't have time to do this very soon, but I'd like to see it happen. So if someone wants to take a swing at this, feel free!

I suppose the easiest integration would be one that simply calls the hpack executable whenever there's an .hpack found in a package directory. If this proves to be popular, we can do a more proper implementation.

I think my use of hpack is mostly predicated on having an automated way to move over current projects - #63 (comment) . Till then I'm going to need to remember to give it a try when I start a new one

[sol]

This is done.