Module Distribution.Package does not export PackageName(PackageName)

[SpencerPark]

Using

resolver: lts-8.11
compiler: ghcjs-0.2.1.9008011_ghc-8.0.2
compiler-check: match-exact

setup-info:
  ghcjs:
    source:
      ghcjs-0.2.1.9008011_ghc-8.0.2:
        url: https://github.com/matchwood/ghcjs-stack-dist/raw/master/ghcjs-0.2.1.9008011.tar.gz
        sha1: a72a5181124baf64bcd0e68a8726e65914473b3b

allow-newer: true

I run into the issue below when running stack setup -v --cabal-verbose with stack Version 1.7.1, Git revision 681c800873816c022739ca7ed14755e85a579565 (5807 commits) x86_64 hpack-0.28.2.

--  While building custom Setup.hs for package comonad-5 using:
      /home/Spencer/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --make -odir /tmp/stack659/comonad-5/.stack-work/dist/x86_64-linux/Cabal-2.0.1.1/setup -hidir /tmp/stack659/comonad-5/.stack-work/dist/x86_64-linux/Cabal-2.0.1.1/setup -i -i. -package=Cabal-2.0.1.1 -clear-package-db -global-package-db -package-db=/home/Spencer/.stack/snapshots/x86_64-linux/lts-8.11/8.0.2/pkgdb /tmp/stack659/comonad-5/Setup.lhs /home/Spencer/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /tmp/stack659/comonad-5/.stack-work/dist/x86_64-linux/Cabal-2.0.1.1/setup/setup -threaded
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/Spencer/.stack/programs/x86_64-linux/ghcjs-0.2.1.9008011_ghc-8.0.2/src/.stack-work/logs/comonad-5.log

    [1 of 2] Compiling Main             ( /tmp/stack659/comonad-5/Setup.lhs, /tmp/stack659/comonad-5/.stack-work/dist/x86_64-linux/Cabal-2.0.1.1/setup/Main.o )

    /tmp/stack659/comonad-5/Setup.lhs:7:31: error:
        Module
        ‘Distribution.Package’
        does not export
        ‘PackageName(PackageName)’

This is on the windows subsystem for linux using a ubuntu distribution. I have been able to boot ghcjs with stack in the past based on the recommendation from the stack docs:

resolver: lts-6.30
compiler: ghcjs-0.2.0.9006030_ghc-7.10.3
compiler-check: match-exact

setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.9006030_ghc-7.10.3:
        url: http://ghcjs.tolysz.org/lts-6.30-9006030.tar.gz
        sha1: 2371e2ffe9e8781808b7a04313e6a0065b64ee51

Note the 8.0.1 version from the stack docs fails for a different reason that is related to ghc producing binaries that have the executable stack flag set which WSL doesn't (and won't) support but that is not the issue that is happening here.

If there is any more information that would help please let me know. Also if there is anything else I should try I would be happy to do so.

[matchwood]

This looks like it might be related to this cabal issue. There seems to be some confusion as to why this occurs. I have managed to successfully build comonad-5 with the lts-9.21 configuration, so it might be worth trying that. Weirdly, I am in the middle of putting together a release for lts-11.20, and the issue recurs there. Why it should work with lts-9.21 but not the others is currently a mystery to me, but I suspect it is due to some interaction between a global cabal installation and one or more local stack installations of cabal.

Do you have a global cabal installation? If so, what version is it?

Also, the error message you pasted didn't actually come from a ghcjs build - it says it was using /home/Spencer/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc, not ghcjs. So from that evidence it might not be an issue with ghcjs at all, but an issue with stack / cabal / the package itself.

[matchwood]

I think this commercialhaskell/stack#3049 explains what is going on. I'm pretty sure that if you make stack use cabal-1.24 (somehow...) then that will resolve the issue.

[SpencerPark]

Hi @matchwood, thank you for the quick reply and the very helpful references to other issues!

I have cabal installed globally. There is this slightly confusing version output but it looks like 1.24.0.2

cabal-install version 1.24.0.2
compiled using version 1.24.2.0 of the Cabal library

I can't even stack exec -- cabal --version because it tries to build the compiler first.

I do get the message Ignoring package Cabal due to wanting version 1.24.2.0 instead of 2.0.1.1 in the debug logs but I hit the same error when running: stack setup --install-cabal 1.24.0.2 -v --cabal-verbose.

I think part of the problem is that this build is too early in the whole stack build lifecycle (the setup) and I don't know what options actually end up getting used in that phase as far as dependency constraints go.

I'll keep looking for solutions, especially in the area of trying to get stack setup to use cabal 1.24, and hopefully come back here with an answer. If you don't mind I would like to keep this open until then?

Thanks again!

[matchwood]

@SpencerPark Oh hang on, I didn't read your log thoroughly enough. I actually thought you were trying to build a package with comonad in it, but the issue is in building the compiler itself? I knew something didn't make sense! It is still quite strange though.

One thing you could try is to set up a dummy package with the lts-8.11 resolver and comonad as a dependency and try to run stack build on that and see what happens. If it succeeds then it should cache the package, and that might solve the issue. As far as I know, all that stack is doing when installing ghcjs is unpacking the archive and then running 'stack build' on it.

[SpencerPark]

I've tried the dummy package setup with lts-8.11 and ghc-8.0.2 and it does get to the build phase but still fails with the same problem. I've also been able to get the stack ls dependencies output now which is

Cabal 1.24.2.0
Dummy 0.0.0.1
... -- all the base dependencies

The dummy project solution did help as I was also able to find some more details about who is using what. stack exec -- which cabal pointed to 1.24.2.0 and similarly every time I found cabal on my system it was 1.24.2.0. The only place where 2.0.1.1 showed up was in the ghc-8.0.2 directory under new-cabal which I am not sure how/when that got there but I feel I must have run --upgrade-cabal in the past potentially trying to fix a similar situation.

Nevertheless, I was able to properly run stack setup --install-cabal 1.24.2.0 in this dummy package (not the original package, the dummy package is important for any future readers of this comment because you need to already have the compiler built as the cabal install appears to happen after that phase?) and got the cabal replaced! The system cabal associated with ghc-8.0.2 is now 1.24.2.0 and everything is back on track.

/home/Spencer/.stack/programs/x86_64-linux/ghc-8.0.2/new-cabal/ is where that cabal was installed and I don't know what I did in the past to break that in the past but all is good now! commercialhaskell/stack#3049 did indeed seem to be the issue.

Thank you very much for all your help with this!

[matchwood]

Glad you got it working! Can I just check that the dummy package you are referring to is one you were trying to build with ghc and you encountered the same issue there?

By the way I got the impression, from poking around in other issues, that it might be possible to solve this issue by directly specifying the cabal version in the stack.yaml used in the ghcjs tarball, but I haven't had a chance to test this yet. I'll update this issue when I get a chance to try it out.

[SpencerPark]

Yes I set up a dummy package with

resolver: lts-8.11
# compiler: ghcjs-0.2.1.9008011_ghc-8.0.2
compiler: ghc-8.0.2
compiler-check: match-exact

and a cabal file with

name:                Dummy
version:             0.0.0.1
synopsis:            Dummy project
build-type:          Simple
cabal-version:       >=1.10

library
  build-depends: base, comonad

but as it was using the same ghc version as the ghcjs attempt, it was also sharing the same global (with respect to the ghc version) cabal. The ghcjs version based on ghc-8.0.2 was (from was I could tell) reusing the ghc-8.0.2 stuff while trying to boot the compiler.

If we can pin down the cabal version in the stack.yaml that would be ideal! This would help with making the build more consistent. I will point out though that even specifying a cabal dependency used the snapshot version and built the correct one but still used the global cabal. Cabal seems to be treated differently than the other dependencies.

[matchwood]

Ok great, many thanks for clarifying, just wanted to double check that we were on the same page!