From hecate at haskell.foundation Wed Jan 3 10:47:44 2024 From: hecate at haskell.foundation (=?UTF-8?Q?Theophile_H=C3=A9cate_Choutri?=) Date: Wed, 3 Jan 2024 11:47:44 +0100 Subject: Cabal developers meeting of the 21/12/2023 Message-ID: ## Current affairs 3.10.3: are we missing anything else? Does Julian want anything else? [Covered: Hecate volunteers] 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) 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: I was mostly guided by what arguments were already there and where I could get the extra paths from. Having someone more familiar with how arguments are 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 from 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. . 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: