From hecate at haskell.foundation Sun Nov 5 18:19:51 2023 From: hecate at haskell.foundation (=?UTF-8?Q?Theophile_H=C3=A9cate_Choutri?=) Date: Sun, 5 Nov 2023 19:19:51 +0100 Subject: Cabal-install 3.10.2.0 released Message-ID: Dear all, cabal-install 3.10.2.0 has been released and is available in ghcup as well as on downloads.haskell.org . This allowed the cabal team to refine our release process. Especially, the effort put in by our QA testers has been crucial in validating contributions changing user-facing behaviour. Release notes for cabal-install 3.10.2.0: https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.10.2.0.md You can join the Cabal development community on Matrix at #hackage:matrix.org Cheers, Hécate -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at haskell.foundation Thu Nov 9 20:14:40 2023 From: hecate at haskell.foundation (=?UTF-8?Q?Theophile_H=C3=A9cate_Choutri?=) Date: Thu, 9 Nov 2023 21:14:40 +0100 Subject: Cabal developers meeting of the 09/11/2023 Message-ID: ## Current affairs * Switching to Fourmolu 0.14: https://github.com/haskell/cabal/issues/9424 * Adds script to automatically generate GHCup metadata for Cabal releases: https://github.com/haskell/cabal/pull/9411 * Design a 'Hooks' build type to replace 'Custom': https://github.com/haskell/cabal/issues/9292 Andrea's comments: - I think the implementation of the build-type is secondary; and indeed not useful by itself. - We need to come to an agreement on a design for the new Cabal/package-builder interface that will augment the CLI interface. - I don't think we will be able to completely remove the CLI interface. If we offer a shim for it, we will end up in a situation where stack will be able to build cabal packages with build-type custom (thanks to the shim) but cabal-install won't! We need to build an architecture that is gradually extensible and where backwards compatibility is not a major roadblock. Moreover, it is felt that many important details are lacking: motivations are scarce, there seems to be a disconnect in the discussion. As it is now, the design seems to be too rigid and there are legitimate fears that the cabal team is going to get stuck with it, with no possibility of evolution. If the work is a replication of what exists, we are going to the same dead-end that we're trying to get out of. A meeting will be brokered with the WT consultants in charge of this. ## Reviews needed * cabal-install-solver: fix pkgconf 1.9 --modversion regression: https://github.com/haskell/cabal/pull/9391 * Warn early that overwrite-policy is needed before build: https://github.com/haskell/cabal/pull/9268 * `cabal check` https://github.com/haskell/cabal/pull/8427 It is not mission critical, but it is blocking some further work (e.g. [#8587](https://github.com/haskell/cabal/issues/8587#issuecomment-1435698751), [#6282]( https://github.com/haskell/cabal/issues/6282#issuecomment-1436069519)). The PR has one approval (Andreas Abel). * Fix cabal haddock --open on Windows: https://github.com/haskell/cabal/pull/9428 ## Food for thoughts - Andrea: I wish we could organise modules to separate code related to v1 commands, v2 commands, and common to both. I keep finding confusing what relates to what. Separate hierarchies would help to visualise the different code paths. I have a WIP for this at https://github.com/andreabedini/cabal/tree/split-legacy-commands. It could be worth thinking of splitting v1 commands into a separate executable/library. I could open a RFC issue. Hécate: I agree, it will certainly be helpful to distinguish these modules once time has come to remove the V1 modules. This may not be for tomorrow but at least this work will be useful. fgaz: splitting them into a separate executable can put some pressure on the remaining v1 users to either maintain the v1 executable or improve v2 until it suits their needs. we effectively remove v1 (long overdue) while giving others the opportunity to continue using it - Andrea: I find the situation of IndexUtils very frustrating. Different `Repo` are treated uniformly while their functionality and behaviours are quite different. The frequence of case splitting is evidence for this. I have been working on-and-off on a refactor but there are many design decisions I have not settled upon: i.e. open (G?ADTs) vs closed (type-class). Any advice would be appreciated. Gershom: A refactoring could be tricky but would be welcome. --- Hécate will post a call for QA testers running Windows, in order to break the vicious circle of unusability. Toolchain experts are not necessarily needed at this time but would be welcome nonetheless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at haskell.foundation Thu Nov 23 23:47:37 2023 From: hecate at haskell.foundation (=?UTF-8?Q?Theophile_H=C3=A9cate_Choutri?=) Date: Fri, 24 Nov 2023 00:47:37 +0100 Subject: Cabal developers meeting of the 24/11/2023 Message-ID: ## Current affairs - Andrea: The issue with GHC 9.6, -fplugin and cabal register seems to be affecting many users, including stack and rules_haskell: https://discourse.haskell.org/t/ghcs-fplugin-any-changes-between-9-4-7-and-9-6-2/7656/4 . We had an issue (https://github.com/haskell/cabal/issues/9375) opened last month and we merged a fix (https://github.com/haskell/cabal/pull/9384) about three weeks ago. I am not expecting the release gods to get their hands dirty again but could we make a minor release for this patch? - Hécate: No problem for a 3.10.3.0 patch release, we need to ship https://github.com/haskell/cabal/pull/9459 anyway - Hécate: No plan for patch releases for 3.8 and 3.6. - Andrea: [#9374](https://github.com/haskell/cabal/pull/9374) (Guard PackageInfo behind cabal-version: 3.10) we need to make a decision about what to do. Further discussion is at https://github.com/haskell/cabal/issues/9331. - Mikołaj has a plan: https://github.com/haskell/cabal/issues/9331#issuecomment-1792219043 - Javier: https://github.com/haskell/cabal/pull/9462 (`default-constraints` proposal): I'd like to have a first discussion on whether the proposal is considered beneficial or not, and discuss alternatives to it. - `package-constraints` seems to be a more fitting name - An RFC for the design for the PR will be opened ## Review needed - Andrea: I had https://github.com/haskell/cabal/pull/9123 opened for a while, blocked on a CI failure on Windows. Can we get someone with Windows experience to look at the failure ( https://github.com/haskell/cabal/actions/runs/6480591351/job/17596418675#step:18:1663 )? - No clear resolution for this problem at this time - Javier can't in fact run the test-suite in Windows on this branch. - Andrea: https://github.com/haskell/cabal/pull/9320 on standalone foreign libs. I am happy to extend the documentation but we need to know what we want to say. - Yvan would be happy to help on that :) - Yvan: https://github.com/haskell/cabal/pull/9159, it's mainly code refactoring, Andrea pair-programmed with me on this one. - Yvan: Stuck with a bug on https://github.com/haskell/cabal/pull/9160, it's a low-hanging fruit to improve `cabal-install` output. - Hécate: Looks like it's a matter of changing hashes? https://github.com/haskell/cabal/actions/runs/6783137983/job/18436767543?pr=9160#step:15:18 - Yvan: Not only https://github.com/haskell/cabal/pull/9160#issuecomment-1798232254 - Rodrigo: Almost done with https://github.com/haskell/cabal/pull/9464: reworks a bit --enable-coverage and "re-fixes" #5213, #4798 and will fix #6440. - Rodrigo: Did this fix on a whim https://github.com/haskell/cabal/issues/9448. I think this happens once in a while and I've put forward a pragmatic fix. I don't understand what other situation can trigger this error. ## Food for thoughts - Andrea: I have played a bit with the lexer to add tokens for whitespace and comments (maybe a humble step towards exact-printing but I won't make such a claim). While doing that I noticed the token `TokFieldLine` never gets emitted by the lexer (I tested this on the whole Hackage). I am not very well versed in this, does anybody have a clue? - Hécate: It might actually be impossible for the Lexer to emit this token, due to overlap with other things. -------------- next part -------------- An HTML attachment was scrubbed... URL: