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

Created on 27 Nov 2016 · 20Comments · Source: haskell/cabal

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)’

solver stanzcustom-setup bug

Source

omefire

All 20 comments

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?

ezyang on 27 Nov 2016

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 on 27 Nov 2016

@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

omefire on 27 Nov 2016

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.

ezyang on 27 Nov 2016

👍1

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

omefire on 27 Nov 2016

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.

omefire on 27 Nov 2016

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

ezyang on 28 Nov 2016

No, I didn't.

omefire on 28 Nov 2016

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.

omefire on 28 Nov 2016

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 https://github.com/ekmett/distributive/issues/39 and https://github.com/haskell/cabal/issues/4683.

23Skidoo on 14 Oct 2017

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.

23Skidoo on 15 Oct 2017

--  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?

mgsloan on 17 Dec 2017

@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).

23Skidoo on 17 Dec 2017

👍1

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.

mgsloan on 17 Dec 2017

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

hvr on 17 Dec 2017

@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?

mgsloan on 23 Dec 2017

Is there any movement on this?

IvanMalison on 21 Feb 2018

@IvanMalison Can you reproduce this issue?

23Skidoo on 21 Feb 2018

I couldn't reproduce the issue. I checked out cabal from around the date of this issue (8744e30b736995a5d9271e99f2dfc861210686f9) 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.