Package request: haskell.compiler.ghc<X><Y><Z> for GHC X.Y.Z (latest major versions)

[mpilgrem]

Motivation: https://github.com/commercialhaskell/stack/issues/6536

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

already provides haskell.compiler.ghc<X><Y><Z> for many recent versions of GHC X.Y.Z but, apparently systematically, not the most recent version of GHC in the GHC X.Y series.

For example:

GHC 9.4.8: Missing (but haskell.compiler.94 exists) GHC 9.4.7: haskell.compiler.ghc947 GHC 9.4.6: haskell.compiler.ghc946 GHC 9.4.5: haskell.compiler.ghc945 GHC 9.4.4 and earlier: missing (but that is understandable)

Stack can use only GHC versions that are in the Nix package repository, and assumes that GHC X.Y.Z is available as haskell.compiler.ghc<X><Y><Z>.

[eclairevoyant]

nix repl -f '<nixpkgs>'
Nix 2.21.0
Type :? for help.
Loading installable ''...
Added 20858 variables.
nix-repl> haskell.compiler.ghc948
«derivation /nix/store/4p1xih5cnc6v54kr6aaw5m893fwx1y9b-ghc-9.4.8.drv»

seems it exists.

[mpilgrem]

@eclairevoyant, thanks - but now I am confused (I am not a Nix user myself): does the search function at https://search.nixos.org/packages not return all packages? The Stack user who raised the motivating issue gave the example of haskell.compiler.ghc96 but no haskell.compiler.ghc964. Perhaps they were also relying on the search functionality.

[eclairevoyant]

The search page is definitely not exhaustive, which is why I used the REPL here.

Regarding that user's example, haskell.compiler.ghc964 also exists.

[mpilgrem]

@eclairevoyant, sorry if my issue was misconceived. @harris-chris, it appears that Nix does include the package to which you referred.

[harris-chris]

I didn't realize that the nixpkgs search page isn't comprehensive, that's interesting. For the nixpkgs that I'm using, (23.11), I don't see that haskell.compiler.ghc964 exists (see snippet below). It may be that it exists in some commits of nixpkgs but not anothers? If so then this relates to my other point, which is that relying on the user's <nixpkgs> is not perfectly robust - I nowadays use flakes almost exclusively and had my <nixpkgs> set to 21.05 or something quite ancient.

nix-repl> haskell.compiler.ghc964
error:
       … while evaluating the attribute 'compiler.ghc964'

         at /nix/store/j8han9cf3g8vba52yhiklaa6a500pcbv-source/pkgs/top-level/haskell-packages.nix:66:3:

           65|
           66|   compiler = {
             |   ^
           67|     ghc865Binary = callPackage ../development/compilers/ghc/8.6.5-binary.nix {

       error: attribute 'ghc964' missing

       at «string»:1:1:

            1| haskell.compiler.ghc964
             | ^
       Did you mean one of ghc924, ghc94, ghc944, ghc96 or ghc962?

[eclairevoyant]

9.6.4 is only present on unstable, currently. And I'd recommend deleting whatever channels you have and pinning them to your config flake inputs (via the nix.nixPath option), which would avoid bitrotted channels while still allowing you to use <nixpkgs>.

[harris-chris]

Thanks, yes, it's all working now in my case. Are you interested in a more general solution? It seems unwise to assume that everybody will having their nixpkgs set to unstable.