Proposal: allow one to give a path to an hpack executable rather than using the hack bundled with stack.
Suggestion: include a command line option such as --hpack=<PATH_TO_HPACK>
Use case: we ran into a couple issues with hpack, one of which is fixed on hpack/master and another which is fixed in a PR that is not yet merged. That means we have to wait for both hpack to accept the PR change, as well as wait for the next stack release that bundles those hpack changes. That is a double delay for release cycles. Allowing a custom hpack gives us the freedom to change hpack for our custom needs now and not have to wait for them to be released (which could be months away).
I may look into code changes according to this proposal. I am opening this issue to get feedback on the idea, as well as to double check that I didn't miss an existing option or workaround for this.
Thank you for your consideration!
Proposal: allow one to give a path to an
hpackexecutable rather than using thehackbundled withstack.Suggestion: include a command line option such as
--hpack=<PATH_TO_HPACK>Use case: we ran into a couple issues with
hpack, one of which is fixed onhpack/masterand another which is fixed in a PR that is not yet merged. That means we have to wait for bothhpackto accept the PR change, as well as wait for the nextstackrelease that bundles thosehpackchanges. That is a double delay for release cycles. Allowing a customhpackgives us the freedom to changehpackfor our custom needs now and not have to wait for them to be released (which could be months away).I may look into code changes according to this proposal. I am opening this issue to get feedback on the idea, as well as to double check that I didn't miss an existing option or workaround for this.
Thank you for your consideration!