Use hpack executable from PATH if it is newer than what stack ships with?

[sol]

The latest version of hpack has a --numeric-version option. With this it would be possible for stack to check if there is a newer version of hpack installed on a users system and if so use that instead of the bundled hpack.

• Check if hpack is on the users PATH, if no use bundled hpack
• If yes, try hpack --numeric-version, if it fails use bundled hpack
• If it succeeds then check if it is newer than the bundled hpack and use it if so, otherwise use bundled hpack

This is just a suggestion, not a request to add.

(cc @scott-fleischman who did related stuff before)

[mgsloan]

Hmm, sure, this makes sense to me!

[amir]

Does this also require introducing a new config to allow the override to happen (e.g., configAllowHpacCommandNewer)?

[quasicomputational]

+1 from me, with a switch to disable if you really want the wired-in hpack.

[vlatkoB]

IMHO, hpack should not be included in stack at all, but should always use external/system installed hpack.

hpack is a separate project, completely unrelated to stack's functionality, has its own pace of release (bug fixes and new features), which will force stack to release more often just to keep up with hpack, or fall behind, increasing the maintenance burden. (For example, latest stack-1.6.5 packs hpack-0.20.0, and hpack is already on version 0.28.0.)

I mean, if you want to use the hpack functionality, you should have hpack installed (likewise, if you want documentation, you have to install haddock, otherwise stack reports about missing bin).

[philderbeast]

Another option aside from being bundled with stack or being picked up from the environment is to use project relative tools, to have stack install a version of a tool relative to the project. These tool versions could then be specified and locked down in the project. I do this at the moment when installing dhall;

With a separate stack-dhall.yaml, I can use a different resolver for tooling than I do for the project;

resolver: lts-12.5
flags: {}
packages: []
extra-deps:
- dhall-1.16.1
- hpack-dhall-0.3.0
- dhall-nix-1.1.5
- hnix-0.5.2
- serialise-0.2.0.0
local-bin-path: __shake-build
work-dir: .stack-work-dhall

> stack install dhall hpack-dhall --stack-yaml=stack-dhall.yaml
> __shake-build/dhall format --inplace default-tests.dhall

Perhaps we could unbundle hpack from stack but then use such tooling if specified for the project by way of a configuration, a tool resolver if you will.