Stack not finding correct GHC via nixpkgs

[harris-chris]

Hello - you may already be aware of this, but there's two ways in which the stack/nix infrastructure can go wrong:

1. The nix expression generated in src/Stack/Nix.hs uses with (import <nixpkgs> {}) - this then relies on the state on the user's machine. This <nixpkgs> will be the nixpkgs in the $NIX_PATH, which might be quite out of date since many people have moved over wholesale to flakes these days.
2. The nixCompilerVersion function in src/Stack/Config.Nix.hs will (not unreasonably) look for a ghc version in nixpkgs that has the name format haskell.compiler.ghc<major><minor><patch>, like haskell.compiler.ghc964. This should work except that the ghc versions in nixpkgs don't always seem to adhere to this format, eg haskell.compiler.ghc96 is ghc 9.6.4, and haskell.compiler.ghc964 doesn't exist.

I'm not sure what the best solution to this is, it might be worth storing a map from resolver -> (nixpkgs commit, nixpkgs ghc package name) in the source code, and then falling back to using the existing approach if a resolver is requested that isn't in the map.

[mpilgrem]

@harris-chris, thanks for reporting. I am at a personal disadvantage in that I am not a Nix user. However, I can look into who makes, and names, GHC versions for Nix.

Looking at: https://search.nixos.org/packages?channel=unstable&from=0&size=50&sort=relevance&type=packages&query=haskell.compiler.ghc

it seems to me that, currently, Nix uses haskell.compiler.ghc<X><Y> for the most recent version (on Nix) of GHC in the GHC X.Y.Z series but does not provide haskell.compiler.<X><Y><Z>. Perhaps that is a change in behaviour at the Nix project.

[harris-chris]

Would you accept a PR for this? I'm not necessarily going to be able to provide one, but if I have some time I'd be happy to attempt it.

…

On Sat, Mar 30, 2024, 5:21 AM Mike Pilgrem ***@***.***> wrote: @harris-chris <https://github.com/harris-chris>, thanks for reporting. I am at a personal disadvantage in that I am not a Nix user. However, I can look into who makes, and names, GHC versions for Nix. — Reply to this email directly, view it on GitHub <#6536 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALDMVSBPWRPWLJA66Y2Q23DY2W5KNAVCNFSM6AAAAABFNWUXVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGY4TSOBSGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mpilgrem]

@harris-chris, pull requests are welcome, but at NixOS/nixpkgs#300085 it has been suggested that Nix packages exist that are not found by https://search.nixos.org/packages. So first, I think we need to establish whether or not there is an upstream issue with missing packages.

[tmplt]

I'm hitting this with stack new test yesodweb/simple using stack 2.13.1: it is looking for ghc964 which is no longer available, in favor of ghc965. I suppose I could trawl thought nixpkgs history and find latest commit with 964 available, but I figure it must be removed for a reason.

Can I tell stack to use 965 instead?

[mpilgrem]

@tmplt, is that correct? If I try the following on Ubuntu (via WSL 2), where <tab> is the TAB key, this is what I experience:

$ nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-unstable
$ nix-channel --update
unpacking channels...
$ nix repl
Welcome to Nix 2.10.3. Type :? for help.

nix-repl> :l <nixpkgs>
Added 21232 variables.
nix-repl> haskell.compiler.ghc<tab>
haskell.compiler.ghc810         haskell.compiler.ghc927         haskell.compiler.ghc964
haskell.compiler.ghc8107        haskell.compiler.ghc928         haskell.compiler.ghc965
haskell.compiler.ghc8107Binary  haskell.compiler.ghc94          haskell.compiler.ghc98
haskell.compiler.ghc865Binary   haskell.compiler.ghc945         haskell.compiler.ghc981
haskell.compiler.ghc90          haskell.compiler.ghc946         haskell.compiler.ghc982
haskell.compiler.ghc902         haskell.compiler.ghc947         haskell.compiler.ghcHEAD
haskell.compiler.ghc92          haskell.compiler.ghc948         haskell.compiler.ghcjs
haskell.compiler.ghc924Binary   haskell.compiler.ghc96          haskell.compiler.ghcjs810
haskell.compiler.ghc925         haskell.compiler.ghc963
haskell.compiler.ghc926         haskell.compiler.ghc963Binary
nix-repl> haskell.compiler.ghc

That list includes haskell.compiler.ghc965.

[tmplt]

It does, as it does on my system. It also happens to include ghc964 which stack was looking for. But what happens if you run the below?

$ nix run nixpkgs#haskellPackages.stack -- new test

On my system it fails to find ghc964. Has an incorrect nixpkgs been pinned internally or by the default template (never used stack before, so I don't know if that could be an error source)?

I'm using Nix 2.18.1. Regression?

[mpilgrem]

I am not a Nix user, but this is my further experience:

$ nix --version # I have upgraded since the post above
nix (Nix) 2.22.0
$ stack new test6536
...
$ cd test6536

Edit stack.yaml to include:

snapshot: lts-22.19 # GHC 9.6.4
compiler: ghc-9.6.5 # Desired compiler
nix:
  enable: true

Then:

$ stack build # Building with Nix integration
...
test6536> build (lib + exe) with ghc-9.6.5
...
Registering library for test6536-0.1.0.0..

behaves as expected.

[harris-chris]

If my recollection is correct, this is because stack is trying to find ghc in the user's local nixpkgs channel, which is not pinned to a specific nixpkgs commit, and so does not necessarily contain any given version of ghc. It may fix things for a given user if they update their nixpkgs channel.