# Cabal meeting (21/12/2023)

Previous meeting notes at: https://hackmd.io/s/H1dR5FkUp

## Current affairs
<!--
Outstanding things on which we have to adjudicate.
Important, of various degrees of urgency
-->

- 3.10.3: are we missing anything else? Does Julian want anything else?
- [Covered: Hecate voluteers] Mikolaj asks humbly: Could somebody ask Julian?
- [Done: approved for 3.10.3, Javier handled the backport, merged.] this is the only apparent non-merged candidate PR (conditionally recommended by grayjay): https://github.com/haskell/cabal/pull/9550
- [MK: Now merged.] [#9525](https://github.com/haskell/cabal/pull/9525) should be merged too, bot got stuck? —F
- We've agreed to release ASAP and not to block the release on anything else, any backports, etc.

- Hécate: [`cabal path`](https://github.com/haskell/cabal/pull/8879)'s UX is subpar at the moment and I can't sign-off on shipping it. It only serves as a glue command for cabal2nix, but only reads the user-wide config file and environment variables. We can:
- Extend `user-config`, it's just annoying™ (-- Fendor)
- Make `path` aware of cabal projects, and unify `path` and [`status`](https://github.com/haskell/cabal/pull/7500) with user-specified outputs and format to ensure backwards compatibility, and add the ghc location as part of the possible outputs. (-- Fendor)
- Merging the two commands has direct benefits for HLS such as:
* Improved start-up times for cabal projects
* Improved time until diagnostics are displayed to the user
* Inform users about project issues (e.g., no build plan) in the UI
* Fewer hacks to find the compilations options given a FilePath
- Merging the two commands should be rather straight forward:
* Rename #7500 `cabal status` to `cabal v2-path` (Only to disambiguate from current `cabal path` in this context). Maybe a new PR would be good: #7500 is overloaded with old conversations. Also, rebasing #7500 looks like a major undertaking.
- Some other ideas for the name of that command: `cabal info` (Javier), `cabal query` (Mike).
* Copy flags of current `cabal path` to `cabal v2-path`
* Remove resolving FilePath's to Unit-ids from `cabal v2-path`
* Review and Merge :)

- A PR author would benefit from a clarification about our (unwritten? if written, link?) policy for "guarding behind `cabal-version`": https://github.com/haskell/cabal/pull/9535#issuecomment-1866354715
- We must chat with the GHC developers to reflect GHC's reality, see why cabal has a list of architectures, a list of aliases and GHC has a different list. We must reconcile the three. Rodrigo: I think the "canonical" definition should be ghc-platform (previously in ghc-boot), as it is an independent package that exposes ArchOS data type that is used by ghc and ghc-toolchain.

- Should write down somewhere the policy for guarding behind. It has come up several times recently. For example: this applies only to .cabal files, not to cabal.project files. Please volunteer and sign up in https://github.com/haskell/cabal/issues/9552

- The STF funding has just now been granted to Well-Typed for the second 4-month term of cabal work (including a bit for maintenance work)
- Hécate: This is not only to implement https://github.com/haskellfoundation/tech-proposals/pull/60?
- Rodrigo: Not it isn't. Mainly, we intend to build upon the work done there by improving cabal-install accordingly.

## Review needed
<!--
We need to take a look at these PRs and help them move on.
Urgent, of various levels of importance
-->

- @Jasagredo [#9527](https://github.com/haskell/cabal/pull/9527): I was mostly guided by what was arguments were already there and where I could get the extra paths from. Having someone more familiar with how are arguments passed at different levels taking a look would be super nice. And in general I think this PR is a big QoL improvement on Windows. Could even benefit of backporting to 3.10 if we want to, otherwise, it is not urgent.
- It is agreed this shall not block the 3.10.3.0 release, but if it arrives in time, then it would be fine.

- A closure to the "PackageInfo not guarded behind `cabal-version` story": https://github.com/haskell/cabal/pull/9525 (unless somebody can spot anything we missed)

- Rodrigo:
- Update changelog for per-component with coverage [#9542](https://github.com/haskell/cabal/pull/9542)
- Account for .buildinfo in repl when build-type: Configure [#9440](https://github.com/haskell/cabal/pull/9440) (fixes #9401)
- Refactor ProjectBuilding into Package Phases [#9524](https://github.com/haskell/cabal/pull/9524), Andrea said he'd look too.

- curl errors in CI: [#9530](https://github.com/haskell/cabal/issues/9530) (with a link to a PR that possibly fixes it inside) It looks pretty disturbing to devX. <meta: putting here for visibility>. Also occurring in #9542

## Food for thought

<!--
We want to start the thinking process amongst ourselves for things that will take time to unfold.
May be important, but not urgent
-->
- Have we settled the revisions controversy yet? (The urgent part is settled, I think)
- the concrete case is almost settled, but let's discuss (https://github.com/haskell/cabal/pull/9523#issuecomment-1866082009)
- the general policy still lacks our preference for prerequisites for revisions (e.g., a build or a test run, https://github.com/haskell/cabal/issues/9531#issuecomment-1859994178)

- Hecate: please use cabal-head (see the README on how to get it), and if possible, file PRs to https://github.com/haskellfoundation/error-message-index with the Cabal errors. There are none documented yet!

## And lest we forget

 _________________________________
/ Happy Christmas (or appropriate \
\ festivity) everyone!            /
 ---------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     || -ffaf1