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 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'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 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)

Review needed

  • @Jasagredo #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
    • Account for .buildinfo in repl when build-type: Configure #9440 (fixes #9401)
    • Refactor ProjectBuilding into Package Phases #9524, Andrea said he'd look too.

  • curl errors in CI: #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

And lest we forget

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