`custom-setup` builds fail when constraining dependencies in the `Cabal-hooks` package stack

[jorisdral]

Describe the bug

When using a SetupHooks.hs script, if any of the other library components indirectly impose a constraint on the dependencies of the custom-setup component, then we can encounter compiler errors like these:

SetupHooks.hs:24:18: error: [GHC-83865]
    • Couldn't match expected type ‘Distribution.Verbosity.Verbosity’
                  with actual type ‘Verbosity’
      NB: ‘Distribution.Verbosity.Verbosity’
            is defined in ‘Distribution.Verbosity’ in package ‘Cabal-3.16.0.0’
          ‘Verbosity’
            is defined in ‘Distribution.Verbosity’ in package ‘Cabal-3.16.0.0’
    • In the first argument of ‘Utils.notice’, namely ‘verb’
      In a stmt of a 'do' block: Utils.notice verb "Hello, world"
      In the expression: do Utils.notice verb "Hello, world"
   |
24 |     Utils.notice verb "Hello, world"
   |                  ^^^^

It's the same type, coming from the same Cabal package with the same version number. I suspect something is wrong with dependency resolution, leading the setup-hooks component to be compiled with two different builds of the same package.

I've seen this happen when changing the index-state, so it's bound to happen to other users too.

To Reproduce

I created a small reproducer with the files listed below. It's probably best to start with an empty cabal store. The first build should work fine, using ghc-9.8.4 and cabal-3.16.0.0.

cabal build all

Then, if we swap out containers==0.7 for containers==0.8 and rebuild:

cabal clean && cabal build all

We run into the compiler errors (output included at the end of this post). I specifically picked containers because it is in the dependency stack for Cabal-hooks, Cabal-syntax, and Cabal. Changing the required version forces a rebuild of these packages, and that triggers the error.

These errors do not occur if I put the containers dependency in the custom-setup component. It only happens if I put the dependency in a different component, like the main library.

cabal.project.local

ignore-project: False
with-compiler: ghc-9.8.4

tmp.cabal

cabal-version:      3.14
name:               tmp
version:            0.1.0.0
build-type:         Hooks

library
    build-depends:
        base ^>=4.19,
        containers==0.7,
        -- containers==0.8,
    default-language: Haskell2010

custom-setup
  setup-depends:
    base ^>=4.19,
    Cabal-hooks ^>= 3.14 || ^>=3.16,

SetupHooks.hs

{-# LANGUAGE OverloadedRecordDot #-}

module SetupHooks (setupHooks) where

import           Distribution.Simple.Flag (fromFlag)
import           Distribution.Simple.Setup (CommonSetupFlags (..))
import           Distribution.Simple.SetupHooks as SetupHooks ( SetupHooks(..), noConfigureHooks, noSetupHooks, Verbosity, PostConfPackageInputs(..), ConfigureHooks(..), ConfigFlags(..) )
import qualified Distribution.Simple.Utils as Utils
import           Distribution.Types.LocalBuildConfig (
                     PackageBuildDescr (..))

setupHooks :: SetupHooks
setupHooks = noSetupHooks {
      configureHooks = myConfigureHooks
    }

myConfigureHooks :: ConfigureHooks
myConfigureHooks = noConfigureHooks {
      postConfPackageHook = Just myPostConfPackageHook
    }

myPostConfPackageHook :: PostConfPackageInputs -> IO ()
myPostConfPackageHook pcpi = do
    Utils.notice verb "Hello, world"
  where
    verb = getVerbosity pcpi.packageBuildDescr

getVerbosity :: PackageBuildDescr -> Verbosity
getVerbosity pbd = fromFlag pbd.configFlags.configCommonFlags.setupVerbosity

Expected behavior

No type mismatches like this should be reported.

System information

• Ubuntu 22.04
• cabal-3-16.0.0
• ghc-9.8.4

I observed the same error a few times using ghc-9.6.7

Additional context

A full log of GHC's output for the second build

Resolving dependencies...
Build profile: -w ghc-9.8.4 -O1
In order, the following will be built (use -v for more details):
 - tmp-0.1.0.0 (lib:tmp) (first run)
[1 of 3] Compiling SetupHooks       ( SetupHooks.hs, dist-newstyle/build/x86_64-linux/ghc-9.8.4/tmp-0.1.0.0/setup/SetupHooks.o )

SetupHooks.hs:24:18: error: [GHC-83865]
    • Couldn't match expected type ‘Distribution.Verbosity.Verbosity’
                  with actual type ‘Verbosity’
      NB: ‘Distribution.Verbosity.Verbosity’
            is defined in ‘Distribution.Verbosity’ in package ‘Cabal-3.16.0.0’
          ‘Verbosity’
            is defined in ‘Distribution.Verbosity’ in package ‘Cabal-3.16.0.0’
    • In the first argument of ‘Utils.notice’, namely ‘verb’
      In a stmt of a 'do' block: Utils.notice verb "Hello, world"
      In the expression: do Utils.notice verb "Hello, world"
   |
24 |     Utils.notice verb "Hello, world"
   |                  ^^^^

SetupHooks.hs:26:25: error: [GHC-18872]
    • Couldn't match type ‘Cabal-3.16.0.0:Distribution.Types.LocalBuildConfig.PackageBuildDescr’
                     with ‘PackageBuildDescr’
        arising from selecting the field ‘packageBuildDescr’
      NB: ‘PackageBuildDescr’
            is defined in ‘Distribution.Types.LocalBuildConfig’
                in package ‘Cabal-3.16.0.0’
          ‘Cabal-3.16.0.0:Distribution.Types.LocalBuildConfig.PackageBuildDescr’
            is defined in ‘Distribution.Types.LocalBuildConfig’
                in package ‘Cabal-3.16.0.0’
    • In the first argument of ‘getVerbosity’, namely
        ‘pcpi.packageBuildDescr’
      In the expression: getVerbosity pcpi.packageBuildDescr
      In an equation for ‘verb’:
          verb = getVerbosity pcpi.packageBuildDescr
   |
26 |     verb = getVerbosity pcpi.packageBuildDescr
   |                         ^^^^^^^^^^^^^^^^^^^^^^
Error: [Cabal-7125]
Failed to build tmp-0.1.0.0. The failure occurred during the configure step.

[jorisdral]

I've managed to create a reproducer, so I've completely rewritten the issue. The bug is fairly crippling for real-world use cases of the Hooks build type (assuming I got the reproducer right and others can reproduce the same bug locally).

@ffaf1 sorry for the ping, but you responded to my last issue and I wanted to bring this under the attention of Cabal devs now that the issue is rewritten

[geekosaur]

cc: @sheaf

[sheaf]

Thanks for pinging me, I will try to take a look but it might not be straight away.

[sheaf]

I have managed to reproduce. Indeed the issue is that there are two different copies of the Cabal library at play; with -dppr-debug I get an error like:

    * Couldn't match type `Cabal-3.16.1.0-ba5f17dcca236189c554604f6c39badf141d5c9e:Distribution.Types.LocalBuildConfig.PackageBuildDescr'
                     with `Distribution.Types.LocalBuildConfig.PackageBuildDescr'
      Note: `Distribution.Types.LocalBuildConfig.PackageBuildDescr'
              is defined in `Distribution.Types.LocalBuildConfig'
                  in package `Cabal-3.16.1.0-71c7366d0caa86ed0c0ce599fbc845cf4be94394'
            `Cabal-3.16.1.0-ba5f17dcca236189c554604f6c39badf141d5c9e:Distribution.Types.LocalBuildConfig.PackageBuildDescr'
              is defined in `Distribution.Types.LocalBuildConfig'
                  in package `Cabal-3.16.1.0-ba5f17dcca236189c554604f6c39badf141d5c9e'.

[sheaf]

I've made some progress with the help of @mpickering. I don't have a fix yet, but note that a workaround is to add Cabal to the build-depends field of the setup-depends stanza, e.g. in your example:

custom-setup
  setup-depends:
    base ^>=4.19,
    Cabal-hooks ^>= 3.14 || ^>=3.16,
    Cabal