Closed chessai closed 11 months 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";
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?
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).
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.
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 withstm-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 overridestm-hamt
the "usual" way; by either adding asource-repository-package
section to cabal.project, or apackages.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