Skip to content

haskell-language-server-8104 doesn't build in flake #1871

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
teto opened this issue May 27, 2021 · 9 comments
Closed

haskell-language-server-8104 doesn't build in flake #1871

teto opened this issue May 27, 2021 · 9 comments

Comments

@teto
Copy link
Contributor

teto commented May 27, 2021

Thanks for adding a flake to this repo, it makes things so much easier !

I just wanted to warn that nix build .#haskell-language-server-8104 was broken for 204fdcb and that I had to pin it to
hls.url = "github:haskell/haskell-language-server?rev=37e0551b0d411e345e250a6ed287103640524a62";

Would be cool to only update the flake if all targets compile.

NB: Also old channel is mentioned at https://github.com/haskell/haskell-language-server#contributing

@berberman
Copy link
Collaborator

Hi, thanks for the report, I believe this issue was fixed in #1870, and nix build sholud work for master. Feel free to re-open the issue if you still encounter this :)

@teto
Copy link
Contributor Author

teto commented May 27, 2021

cool thanks

@teto
Copy link
Contributor Author

teto commented Jun 11, 2021

nix build .#haskell-language-server-901
fails with

   > Setup: Encountered missing or private dependencies:
       > base >=4.5 && <4.15

nix build .#haskell-language-server-8105 fail too. The advantage of flake is the lock file to guarantee that things work. Maybe mark those targets as broken until they are really available ?

@anka-213
Copy link
Contributor

Yes, that's a good point. There is (basic) support for ghc-9.0.1 in HLS now, but the nix-expressions hasn't yet been updated with the info from the cabal-ghc901.project or stack-9.0.1.yaml files, so until that happens, they should be marked as broken.

@teto
Copy link
Contributor Author

teto commented Jun 11, 2021

I've been playing with haskell.nix recently and it seems more powerful than nixpkgs' ecosystem (where you contantly have to fiddle with everything). Any thought ?

@anka-213
Copy link
Contributor

I'm not too familiar with the haskell.nix so I can't really say anything. The only thing I know is that you can't use nixpkgs official binary cache if you use haskell.nix, but I don't know if that makes any practical difference here.

@berberman
Copy link
Collaborator

$ nix build .#haskell-language-server-901
error: builder for '/nix/store/d1i4yrpiyxgqmspdr4kb4s1sldb07rf7-cryptohash-md5-0.11.100.1.drv' failed with exit code 1;
       last 10 log lines:
       > [1 of 1] Compiling Main             ( Setup.hs, /build/Main.o )
       > Linking Setup ...
       > configuring
       > configureFlags: --verbose --prefix=/nix/store/f1bq0spbij6b8sc76han56n64l0h73q0-cryptohash-md5-0.11.100.1 --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --docdir=/nix/store/6g9w57a8i848jvfwkp76ilmj68k8aq4r-cryptohash-md5-0.11.100.1-doc/share/doc/cryptohash-md5-0.11.100.1 --with-gcc=gcc --package-db=/build/package.conf.d --ghc-options=-j8 +RTS -A64M -RTS --disable-split-objs --enable-library-profiling --profiling-detail=exported-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --disable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --ghc-option=-split-sections --extra-lib-dirs=/nix/store/9m4hy7cy70w6v2rqjmhvd7ympqkj6yxk-ncurses-6.2/lib --extra-lib-dirs=/nix/store/0d71ygfwbmy1xjlbj1v027dfmy9cqavy-libffi-3.3/lib --extra-lib-dirs=/nix/store/lqwgi0in94ll5fwsbh8ligvn8l0vqn7v-gmp-6.2.1/lib
       > Using Parsec parser
       > Configuring cryptohash-md5-0.11.100.1...
       >
       > Setup: Encountered missing or private dependencies:
       > base >=4.5 && <4.15
       >
       For full logs, run 'nix log /nix/store/d1i4yrpiyxgqmspdr4kb4s1sldb07rf7-cryptohash-md5-0.11.100.1.drv'.
error: 1 dependencies of derivation '/nix/store/lx1hl5k82312yacsb5xr5pf53iszjfml-uuid-1.3.15.drv' failed to build
error: 1 dependencies of derivation '/nix/store/j50yzn5bvm7azgvs1xjwnpcg5psdqiw5-lsp-1.2.0.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/fb0jk5j4fxzvqj6w31xjq449brcgbwhd-rebase-1.6.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/4wvn00x2ylnsdpg0qfvxgj15fhnd3cbh-haskell-language-server-1.1.0.1.drv' failed to build

It seems that some packages in HLS dependencies tree are broken. I guess this kind of fixes should be done in nixpkgs, or we could override them for HLS temporarily, but that would require us to build many packages. For cabal-ghc901.project or stack-9.0.1.yaml, I have no idea how to bind them with the existing nix exprs. Afaik cabal.project is a part of cabal-install, which we don't use in nix build.

@anka-213
Copy link
Contributor

anka-213 commented Jun 12, 2021

Yes, the solution would be to manually override all of those packages in the nix expression. cryptohash-md5 and a bunch of others are included in the allow-newer section in the cabal-ghc901.project file, so they would need to use doJailbreak in the nix files, and those with upstream patches would require something like

overrideCabal package.name { 
  patches = [ (fetchPatch { url = "https://github.com/user/repo/pull/1234.patch"; sha256= "...";})];
}

or overriding the src attribute with the same revisions as are mentioned in the cabal-ghc901.project and stack-9.0.1.yaml in a similar manner to what was done in #1870.

It would probably make sense to upstream the doJailbreaks to nixpkgs, but I don't know how much sense it would make to do so with all the other patches? Maybe it does? I don't know what the nixpkgs policies are for adding patches for haskell packages.

I don't know if haskell.nix has support from automatically extracting the list of patches from cabal.project/stack.yaml or if that would be a path worth taking.

@anka-213
Copy link
Contributor

It would also make sense to submit patches to the upstream libraries for extending their version bounds, so we don't need allow-newer, but that's a separate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants