languages/haskell: respect existing binaries during HLS resolution

[dathegreat]

Fixes a bug I encountered where NVF's pinned nixpkgs drifted far enough out of sync with one of my haskell project's pinned nixpkgs that the NVF-supplied HLS and my shell-supplied GHC stopped playing nicely together.

From the block comment I left in source:

      HLS binaries are incredibly picky about which GHC version they run against
      -- even failing between two GHC builds with identical version numbers, because one has a newer ABI.

      Because of this, we shouldn't assume our provided HLS version is the right
      one for a given project. Appending to PATH with `--suffix` takes advantage
      of PATH's first-match lookup, so an existing HLS already in
      the user's dev environment is found first and takes precedence over ours.
      This way we provide a useful default without clobbering existing setups.

I can confirm that using --suffix no longer clobbered the HLS supplied by my dev shell, and all my haskell tooling worked as expected again.

Sanity Checking

• I have updated the changelog as per my changes
• I have tested, and self-reviewed my code
• My changes fit guidelines found in hacking nvf
• Style and consistency
  • I ran Alejandra to format my code (nix fmt)
  • My code conforms to the editorconfig configuration of the project
  • My changes are consistent with the rest of the codebase
• If new changes are particularly complex:
  • My code includes comments in particularly complex areas
  • I have added a section in the manual
  • (For breaking changes) I have included a migration guide
• Package(s) built:
  • .#nix (default package)
  • .#maximal
  • .#docs-html (manual, must build)
  • .#docs-linkcheck (optional, please build if adding links)
• Tested on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

---

Add a 👍 reaction to pull requests you find important.

[github-actions]

🚀 Live preview deployed from 5bd50f1

View it here:

Debug Information

Triggered by: dathegreat

HEAD at: feature/respect-existing-hls-path

Reruns: 3475

[snoweuph]

btw you could also just modify vim.languages.haskell.extensions.haskell-tools.setupOpts.hls.cmd = ["haskell-language-server" "--lsp"] directly for your config, to not ship a hsl with your nvf config.

We generally prefer not using the PATH provided bins in NVF, but instead nix managed versions.
If people want to use the versions from their PATH, that is fine, but shouldn't really become default in nvf IMO.

@horriblename whats your opinion on this?

[horriblename]

perhaps a good time to revisit #1180 (comment)
(raf agreed to add a toggle for using either PATH or builtin, but I don't think we really talked about PATH+builtin fallback)

suffixing goes against the rest of nvf so someone else might trip over that thinking the nvf hls has priority, so I don't think that's the way to go

I think i'd rather keep the current behavior till we add said toggle for #1180