Is it desired behavior for shell.nix to install haskell-language-server dependencies, but not ghcide dependencies?

[codygman]

Right now shell.nix only lists the dependencies of haskell-language-server, but the cabal project includes ghcide. That means that right now that haskell-language-server.cabal's dependencies listed in shell.nix are installed by nix, but then cabal has to install ghcide's dependencies.

Is this desired behavior? You could list the superset of ghcide and haskell-language-servers dependencies so all get the advantage of installing from cache. Note that like the shell.nix comment I'm trying to further "leverage the nix cache in as much as possible..." and this isn't an issue to try and "replace Cabal/Stack with Nix" as it explicitly says it doesn't try to do.

As an example if you run cabal build inside of the shell in shell.nix you get:

[cody@nixos:/tmp/newfolder]$ git clone https://github.com/haskell/haskell-language-server --recurse-submodules && cd haskell-language-server && PAGER=cat git log --oneline -n1 && nix-shell --run "cabal new-build"
Cloning into 'haskell-language-server'...
...
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: ghcide-0.2.0 (user goal)
[__1] rejecting: ghcide:!test (constraint from config file, command line flag,
or user target requires opposite flag selection)
[__1] trying: ghcide:*test
[__2] trying: ghcide:-ghc-lib
[__3] unknown package: tasty-quickcheck (dependency of ghcide -ghc-lib *test)
[__3] fail (backjumping, conflict set: ghcide, tasty-quickcheck,
...

This is because tasty-quickcheck isn't listed as a dependency. A "fix" is to call cabal update so that cabal then goes ahead and installs these dependencies, but that's suboptimal and the reason for my question.

I'd be happy to submit a PR if this isn't desired behavior.

[jneira]

I think @pepeiborra is building hls with nix frequently and maybe could confirm it

[pepeiborra]

Have you seen the comments in shell.nix?

[codygman]

Have you seen the comments in shell.nix?

Yes, that's why in my comment I said:

Note that like the shell.nix comment I'm trying to further "leverage the nix cache in as much as possible..." and this isn't an issue to try and "replace Cabal/Stack with Nix" as it explicitly says it doesn't try to do.

Feel free to close though If this isn't desired or I'm wrong in my assessment.

[pepeiborra]

Omitting tasty-quickcheck is not the desired behaviour, so happy to get a PR for that. But a command line like the one you are using isn't expected to work either without a cabal update, since the expectation is that there will always be gaps in the Nix Hackage snapshot.

[jneira]

@codygman it still would need a pr?

[jneira]

@pepeiborra maybe this could be closed by #639?