Cabal meeting (21/12/2023)

# Cabal meeting (21/12/2023) Previous meeting notes at: https://hackmd.io/s/H1dR5FkUp ## Current affairs  - 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  - @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  - 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 ```