Cabal Build Error: Module ‘Distribution.Package’ does not export ‘PackageName(PackageName)’

[omefire]

Creating package registration file:
I keep getting this error when trying to build cabal with cabal new-build cabal-install:

/Users/omefire/Projects/cabal/dist-newstyle/tmp/package-registration-144128232716531729
Configuring hackage-security-0.5.2.2...
[1 of 1] Compiling Main             ( /Users/omefire/Projects/cabal/dist-newstyle/build/distributive-0.5.0.2/setup/setup.hs, /Users/omefire/Projects/cabal/dist-newstyle/build/distributive-0.5.0.2/setup/Main.o )

/Users/omefire/Projects/cabal/dist-newstyle/build/distributive-0.5.0.2/setup/setup.hs:8:31:
    Module
    ‘Distribution.Package’
    does not export
    ‘PackageName(PackageName)’

[ezyang]

Well, that error looks like distributive's custom setup is being linked against Cabal HEAD, which made an API-breaking change to the signature of PackageName. It's a bit puzzling that no one else has seen this problem though. Which version of cabal are you bootstrapping with?

[omefire]

I currently have a stop gap, which is pretty simple:

• Edit the file /Users/omefire/Projects/cabal/dist-newstyle/build/distributive-0.5.0.2/setup/setup.hs:8:31 to `import Distribution.Package (PackageName, PackageId, ...)
• Edit the file /Users/omefire/Projects/cabal/Cabal/Distribution/Package.hs:21toPackageName(..)`

[omefire]

@ezyang ,

omefire-Mac:distributive omefire$ cabal --version
cabal-install version 1.24.0.0
compiled using version 1.24.0.0 of the Cabal library 

[ezyang]

That definitely doesn't seem like the right way to go to workaround. A more robust workaround would be to vendor distributive (add your checkout of it to packages in cabal.project.local) and edit it to have a Simple build-type rather than Custom.

Maybe another way to solve the problem is to only build cabal executable using 1.24 cabal-install (since I don't believe distributive is a bootstrap dependency) and then use the resulting cabal-install executable for development.

But it's worth figuring out why the wrong version of Cabal is being selected.

[omefire]

Hey @ezyang , could u plz check ur IRC client ? I sent u soe msgs ?

[omefire]

Update: the above workaround I suggested doesn't work! neither does the ones suggested by @ezyang (at least, not for me. but maybe, I misunderstood him and made mistakes while applying his suggestions.)

What worked for me in the end, was to just checkout cabal into a fresh folder.

The reason for the failure might be the fact that there's some kind of global state being kept based on the folder path.

[ezyang]

Hmm, did you have a cabal.project.local file in your old directory?

[omefire]

No, I didn't.

[omefire]

Anyway, the issue is being resurfaced anytime I make a change to cabal-install.cabal, even with the new folder. so, that workaround sadly doesn't work.

[23Skidoo]

The issue here seems to be that distributive has a custom-setup section with a Cabal -any dependency, while it actually doesn't support all versions of Cabal. Closing in favour of ekmett/distributive#39 and #4683.

[23Skidoo]

What's a bit weird here is that distributive-0.5.0.2 doesn't have a custom-setup section, so we should've defaulted the dependency on Cabal to < 2.0. Needs to be investigated.

[mgsloan]

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

    [1 of 2] Compiling Main             ( /tmp/stack4505/semigroupoids-5.1/Setup.lhs, /tmp/stack4505/semigroupoids-5.1/.stack-work/dist/x86_64-linux/Cabal-2.0.0.2/setup/Main.o )
    
    /tmp/stack4505/semigroupoids-5.1/Setup.lhs:7:31: error:
        Module
        ‘Distribution.Package’
        does not export
        ‘PackageName(PackageName)’

Would be really good to avoid breaking changes to APIs that are likely to be imported in Setup.hs . Can the re-export of PackageName be re-added, or is the type wholly gone on Cabal 2.0? It'd be nice to at least get older versions of these @ekmett packages building.

Perhaps the signatures of the Cabal API should be monitored to avoid such breaking changes? Alternatively, have a test-suite that builds lots of hackage packages that have custom Setup?

[23Skidoo]

@mgsloan PackageName is an abstract type in 2.0+. I see that semigroupoids-5.1 has build-type: Custom, but doesn't have a custom-setup stanza. cabal-install compiles setup scripts against lib:Cabal < 2.0 in such cases (which is usually 1.24.something).

[mgsloan]

I see, thanks for the info! Maybe stack should have similar logic. Should it be fairly reliable to mix and match Cabal library versions in the same package DB / build plans? I suppose since package DBs are quite mutable for cabal-install and used between versions, it probably should indeed be safe to mix and match Cabal versions within a single build plan.

[hvr]

Fwiw, https://matrix.hackage.haskell.org/package/semigroupoids looks perfectly fine.

[mgsloan]

@hvr That's very curious. Is the matrix using Cabal-1.24 or Cabal-2.0? When looking at the matrix, how can you tell the build plan that was successful?

[colonelpanic8]

Is there any movement on this?

[23Skidoo]

@IvanMalison Can you reproduce this issue?

[grayjay]

I couldn't reproduce the issue. I checked out cabal from around the date of this issue (8744e30) and tried to build that version of cabal using itself, with GHC 8.0.1 and the command cabal new-build cabal-install --index-state=2016-11-26T00:00:00Z. The install plan didn't contain distributive. Then I tried adding a dependency on distributive directly to cabal-install, but cabal correctly applied a < 1.25 constraint to distributive's setup dependency on Cabal (rejecting: distributive-setup.Cabal~>Cabal-1.25.0.0 (conflict: distributive => distributive-setup.Cabal>=1.18 && >=1.8 && <1.25)).

I did notice that #3939 lowered the bound on Cabal from 2.0 to 1.25, so maybe this issue occurred with cabal-install built before #3939 used to build the project after #3896.

[grayjay]

Closing, since this issue probably only affected an unreleased version of cabal.