input-output-hk / haskell.nix

Alternative Haskell Infrastructure for Nixpkgs
https://input-output-hk.github.io/haskell.nix
Apache License 2.0
558 stars 240 forks source link

Changing package set used by `tools` #1981

Closed chessai closed 11 months ago

chessai commented 1 year ago

I'm trying to enable haskell-language-server on a haskell.nix project using GHC 8.10.7, with simply haskell-language-server = { };. This fails with stm-hamt failing to build, because that package is incompatible with hashable < 1.4, and GHC 8.10.7 has hashable 1.3.x. I prepared a patch. The problem arises when I try to override stm-hamt the "usual" way; by either adding a source-repository-package section to cabal.project, or a packages.stm-hamt.patches = [ ./my-cool-patch ];: The build still fails, as though I hadn't updated the package at all. This makes me think that anything in tools' doesn't care about my overrides. How can I make it so that the new stm-hamt is respected?

Cheers

hamishmack commented 1 year ago

I'm trying to enable haskell-language-server on a haskell.nix project using GHC 8.10.7

We gave up building HLS from hackage and instead use a GitHub pin of the source repo. The HLS GitHub repo contains a cabal.project file with all the work arounds needed. To use the same pinned commit that is built in the haskell.nix CI you can do:

  tools.haskell-language-server.src = pkgs.haskell-nix.sources."hls-2.0";
chessai commented 1 year ago

I don't really know if this answers my question. I am not trying to use a different HLS version necessarily. But HLS is failing to build because on of its dependencies fails to build. So I'm trying to figure out how I can override its dependency. I tried amending the cabal.project of my project and also applying patches in modules, but the changes were not picked up. If I point tools.haskell-language-server.src at the correct commit of hls, would that work?

hamishmack commented 1 year ago

I tried amending the cabal.project of my project

Each tools builds using their own project (only the GHC version used is inherited from the parent project). By default the cabalProject used is essentially just packages: .. You can pass all the same arguments to them. So for instance if you want to try to build the latest version from hackage, but :

tools.haskell-language-server = {
  version = "latest"; # This is the default so you can leave it out
  cabalProject = ''
    packages: .

    source-repository-package
      type:git
      location: https://github.com/pepeiborra/ekg-json
      tag: 7a0af7a8fd38045fd15fb13445bdcc7085325460
  '';
  sha256map."https://github.com/pepeiborra/ekg-json"."7a0af7a8fd38045fd15fb13445bdcc7085325460" = "sha256-fVwKxGgM0S4Kv/4egVAAiAjV7QB5PBqMVMCfsv7otIQ=";
};

If you look in the cabal.project for HLS 2.0 you will see there are quire a few other things needed to get it to build. Even if you include them all, sometimes the plugin packages are out of date in hackage or the wrong version is picked by the planner (using the source repo effectively pins all of the plugin package versions to the version in the repo). We decided it was too difficult to maintain out own cabal.project for using with the hackage haskell-language-server.

If I point tools.haskell-language-server.src at the correct commit of hls, would that work?

It should. However if it includes source-repository-packages other than the ones we have in the default sha256map, you may need to pass them in too.

tools.haskell-language-server = {
  src = my-pinned-hls;
  sha256map."https://github.com/pepeiborra/ekg-json"."7a0af7a8fd38045fd15fb13445bdcc7085325460" = "sha256-fVwKxGgM0S4Kv/4egVAAiAjV7QB5PBqMVMCfsv7otIQ=";
};

Note: That particular ekg-json commit hash is in the HLS 2.0 cabal.project and we include it in the default sha256map (so it can be left out).

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.