No way to disable hpack running

[phadej]

If I have used non-upstream version of hpack, now I'm forced to also use non-upstream version of stack - as I cannot disable regeneration of cabal files.

This now breaks many of our CI builds as they pull the latest stack binary in. Some of cabal files are generated with patched hpack or manually edited afterwards.

[phadej]

I don't know how to fix the issue. Maybe we should add file-edition-time checks after all?

[simonmichael]

I think it regenerates even if the cabal file has a newer timestamp than the hpack file, which is perhaps unintuitive and was inconvenient for #1814.

[mgsloan]

Perhaps this is one reason to use hpack as an external binary, as discussed in #1800 . If we do really care about the process invocation overhead, we could do the following:

• Invoke hpack as an external process if it exists
• Otherwise use the hpack library that's been compiled into stack

As for having manual edits to your cabal file, my response would be "don't do that". I suppose you could have some hpack or stack.yaml configuration that suppresses generation of your cabal file.

[mgsloan]

Having a --[no-]hpack flag would be a fine addition.

[sol]

I agree that a --[no-]hpack flag would be something useful.

Regarding manual editing cabal files, I understand that this is due to missing features in hpack and I'm sorry for that. @phadej I'm trying to somehow free up the time to get the missing stuff on master (most importantly conditionals + flags I assume).

[phadej]

I can work on --[no-]hpack flag. The major problem is that findOrRegenerateCabalFile and all it's callers would need to pass thru HpackOpts or some other structure.

I'm not sure how to do that, is adding MonadReader env m, HasHpackOpts env to the call chains ok approach?

Why HpackOpts? even it would be on/off currently, you never knows when hpack get's new optional features we might want to have (e.g. optionally generating version bounds).

[phadej]

@sol and @mgsloan, sorry for me being impatient :)

[mgsloan]

No worries! I'd probably put it in GlobalOpts. If we get a bunch of hpack options they can get factored into a datatype when that happens.