Open harris-chris opened 3 months ago
@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.
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.
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 https://github.com/commercialhaskell/stack/issues/6536#issuecomment-2027699822, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALDMVSBPWRPWLJA66Y2Q23DY2W5KNAVCNFSM6AAAAABFNWUXVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGY4TSOBSGI . You are receiving this because you were mentioned.Message ID: @.***>
@harris-chris, pull requests are welcome, but at https://github.com/NixOS/nixpkgs/issues/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.
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?
@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
.
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?
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.
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.
Hello - you may already be aware of this, but there's two ways in which the stack/nix infrastructure can go wrong:
src/Stack/Nix.hs
useswith (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.nixCompilerVersion
function insrc/Stack/Config.Nix.hs
will (not unreasonably) look for a ghc version innixpkgs
that has the name formathaskell.compiler.ghc<major><minor><patch>
, likehaskell.compiler.ghc964
. This should work except that the ghc versions in nixpkgs don't always seem to adhere to this format, eghaskell.compiler.ghc96
is ghc 9.6.4, andhaskell.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.