## 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.
