## Current affairs * Switching to Fourmolu 0.14: https://github.com/haskell/cabal/issues/9424 * Adds script to automatically generate GHCup metadata for Cabal releases: https://github.com/haskell/cabal/pull/9411 * Design a 'Hooks' build type to replace 'Custom': https://github.com/haskell/cabal/issues/9292 Andrea's comments: - I think the implementation of the build-type is secondary; and indeed not useful by itself. - We need to come to an agreement on a design for the new Cabal/package-builder interface that will augment the CLI interface. - I don't think we will be able to completely remove the CLI interface. If we offer a shim for it, we will end up in a situation where stack will be able to build cabal packages with build-type custom (thanks to the shim) but cabal-install won't! We need to build an architecture that is gradually extensible and where backwards compatibility is not a major roadblock. Moreover, it is felt that many important details are lacking: motivations are scarce, there seems to be a disconnect in the discussion. As it is now, the design seems to be too rigid and there are legitimate fears that the cabal team is going to get stuck with it, with no possibility of evolution. If the work is a replication of what exists, we are going to the same dead-end that we're trying to get out of. A meeting will be brokered with the WT consultants in charge of this. ## Reviews needed * cabal-install-solver: fix pkgconf 1.9 --modversion regression: https://github.com/haskell/cabal/pull/9391 * Warn early that overwrite-policy is needed before build: https://github.com/haskell/cabal/pull/9268 * `cabal check` https://github.com/haskell/cabal/pull/8427 It is not mission critical, but it is blocking some further work (e.g. [#8587](https://github.com/haskell/cabal/issues/8587#issuecomment-1435698751), [#6282]( https://github.com/haskell/cabal/issues/6282#issuecomment-1436069519)). The PR has one approval (Andreas Abel). * Fix cabal haddock --open on Windows: https://github.com/haskell/cabal/pull/9428 ## Food for thoughts - Andrea: I wish we could organise modules to separate code related to v1 commands, v2 commands, and common to both. I keep finding confusing what relates to what. Separate hierarchies would help to visualise the different code paths. I have a WIP for this at https://github.com/andreabedini/cabal/tree/split-legacy-commands. It could be worth thinking of splitting v1 commands into a separate executable/library. I could open a RFC issue. Hécate: I agree, it will certainly be helpful to distinguish these modules once time has come to remove the V1 modules. This may not be for tomorrow but at least this work will be useful. fgaz: splitting them into a separate executable can put some pressure on the remaining v1 users to either maintain the v1 executable or improve v2 until it suits their needs. we effectively remove v1 (long overdue) while giving others the opportunity to continue using it - Andrea: I find the situation of IndexUtils very frustrating. Different `Repo` are treated uniformly while their functionality and behaviours are quite different. The frequence of case splitting is evidence for this. I have been working on-and-off on a refactor but there are many design decisions I have not settled upon: i.e. open (G?ADTs) vs closed (type-class). Any advice would be appreciated. Gershom: A refactoring could be tricky but would be welcome. --- Hécate will post a call for QA testers running Windows, in order to break the vicious circle of unusability. Toolchain experts are not necessarily needed at this time but would be welcome nonetheless.