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