Cabal library API breakage in 3.14.0.0

[ulidtko]

Up until version 3.14, the public module Distribution.Simple of Cabal-the-library has been exporting these names:

• GlobalPackageDB
• UserPackageDB
• SpecificPackageDB

as constructors of PackageDB data type (indirectly, via reexport of Distribution.Simple.Compiler).

The patchset #10256, specifically commit 90fbf08, having shuffled the definitions a little bit, is now causing compile errors in either of two forms:

src/Distribution/Extra/Doctest.hs:481:8: error: [GHC-76037]
    Not in scope: data constructor ‘GlobalPackageDB’
    Suggested fix:
      Perhaps you want to add ‘GlobalPackageDB’
      to one of these import lists:
        ‘Distribution.Simple’ (src/Distribution/Extra/Doctest.hs:(66,1)-(68,23))
        ‘Distribution.Simple.Compiler’ (src/Distribution/Extra/Doctest.hs:(69,1)-(70,74))
    |
481 |       (GlobalPackageDB:dbs)
    |        ^^^^^^^^^^^^^^^

with import Distribution.Simple.Compiler (PackageDB(..)) being already there;

or

src/Distribution/Extra/Doctest.hs:70:59: error:
    In module ‘Distribution.Simple.Compiler’:
      ‘GlobalPackageDB’ is a data constructor of ‘PackageDBX’
    To import it use
      import Distribution.Simple.Compiler( PackageDBX( GlobalPackageDB ) )
    or
      import Distribution.Simple.Compiler( PackageDBX(..) )
   |
70 |        (CompilerFlavor (GHC), CompilerId (..), PackageDB, GlobalPackageDB, UserPackageDB, SpecificPackageDB, compilerId)
   |                                                           ^^^^^^^^^^^^^^^

Please at least document this in release notes, as it's a breaking change.

(BTW there's no 3.14.0.0 on https://github.com/haskell/cabal/releases )

[ulidtko]

One more with BuildCommonFlags (bundled, record) pattern synonym: #9718 (comment)

[ulidtko]

One more with SymbolicPathX vs FilePath:

src/Distribution/Extra/Doctest.hs:279:40: error: [GHC-83865]
    • Couldn't match type: [Char]
                     with: Distribution.Utils.Path.SymbolicPathX
                             Distribution.Utils.Path.AllowAbsolute
                             Distribution.Utils.Path.Pkg
                             (Distribution.Utils.Path.Dir Distribution.Utils.Path.PkgDB)
      Expected: PackageDBX
                  (Distribution.Utils.Path.SymbolicPath
                     Distribution.Utils.Path.Pkg
                     (Distribution.Utils.Path.Dir Distribution.Utils.Path.PkgDB))
        Actual: PackageDBX FilePath
    • In the expression:
        SpecificPackageDB $ distPref </> "package.conf.inplace"
      In the second argument of ‘(++)’, namely
        ‘[SpecificPackageDB $ distPref </> "package.conf.inplace"]’
      In the expression:
        withPackageDB lbi
          ++ [SpecificPackageDB $ distPref </> "package.conf.inplace"]
    |
279 |   let dbStack = withPackageDB lbi ++ [ SpecificPackageDB $ distPref </> "package.conf.inplace" ]
    |                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[ulidtko]

... The BuildCommonFlags one puzzles me for good 💭

Seems like the post-refactor API is incomplete; the new pattern synonym BuildCommonFlags should be bi-directional... Yet, with its ViewPatterns definition, it can't.

Hi @sheaf, can I ask you as the implementor of #9718 — am I missing a way to rewrite snippets that use Cabal-the-library like so

miniRepro :: BuildFlags
miniRepro = defaultBuildFlags {buildVerbosity = undefined}

against Cabal 3.14?..

That (I think, correctly) yields:

src/Minirepro.hs:245:13: error: [GHC-16444]
    • non-bidirectional pattern synonym ‘BuildCommonFlags’ used in an expression
    • In a record update at field ‘buildVerbosity’
      and with pattern synonym ‘BuildCommonFlags’.
      In the expression: defaultBuildFlags {buildVerbosity = undefined}
      In an equation for ‘miniRepro’:
          miniRepro = defaultBuildFlags {buildVerbosity = undefined}
    |
245 | miniRepro = defaultBuildFlags {buildVerbosity = undefined}
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Under spoiler, I've minimized a bare ghci-ready model test, to spare us all of traversing Cabal codebase for smoother discussion:

minified example

Foo.hs:

{-# LANGUAGE PatternSynonyms, ViewPatterns #-}

module Foo
  ( Sauce (BuildPun, buildDolor, buildSitamet)
  , defaultSauce
  ) where

-- exported without constructor
data Sauce = Sauce
  { lorem :: Int
  , ipsum :: Bool
  , buildSauce :: CommonSauce
  }

data CommonSauce = CommonSauce
  { dolor :: String
  , sitamet :: Maybe ()
  }

pattern BuildPun :: String -> Maybe () -> Sauce
pattern BuildPun
  { buildDolor
  , buildSitamet
  } <- ( buildSauce -> CommonSauce { dolor=buildDolor, sitamet=buildSitamet })

defaultSauce = Sauce 42 False defaultCommonSauce
defaultCommonSauce = undefined

Bar.hs:

module Bar where

import Foo (Sauce (..), defaultSauce)

example :: Sauce
example = defaultSauce { buildDolor = "WAT" }

Same error message:

Bar.hs:6:11: error: [GHC-16444]
    • non-bidirectional pattern synonym ‘BuildPun’ used in an expression
    • In a record update at field ‘buildDolor’
      and with pattern synonym ‘BuildPun’.
      In the expression: defaultSauce {buildDolor = "WAT"}
      In an equation for ‘example’:
          example = defaultSauce {buildDolor = "WAT"}
  |
6 | example = defaultSauce { buildDolor = "WAT" }
  |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Not a heavy user of pattern synonyms myself, so apologies for perhaps obvious question, and thanks in advance.

[sheaf]

... The BuildCommonFlags one puzzles me for good 💭

To set the verbosity field of BuildFlags in Cabal 3.14 and above, you can do the following:

setBuildFlagsVerbosity :: Verbosity -> BuildFlags  -> BuildFlags
setBuildFlagsVerbosity v flags@(BuildFlags { buildCommonFlags = common )} =
  flags { buildCommonFlags = common { setupVerbosity = v } }

Probably the most backward-compatible way to fix this would be to use lenses that would be provided by the Cabal library, but at the moment the Cabal library is very inconsistent about which lenses it provides. IMO Cabal should expose a Lens' BuildFlags Verbosity that would be usable across versions.

[ulidtko]

That's quite awkward 🫤 Also realize it must be wrapped into CPP version checks (which I see you did in cabal tests).

Wasn't the point of refactor to simplify?..

Anyhow, thanks for the reply, I'll try to adapt to this change as well.