- cabal-devel - Haskell.org

Forging the consensus about the Custom proposal
by Mikolaj Konarski 12 Feb '24

12 Feb '24

Hello, Well-Typed reports that after the long discussion/iteration process the Cabal The Library portion of the Custom proposal as described at https://github.com/haskellfoundation/tech-proposals/pull/60 is "subject to change based on feedback but otherwise we are content with it" and that the preliminary experiments with the prototype implementation produce promising results. The pace of the conversation in the proposal PR seems to have slowed down as well. What could help us reach the consensus regarding the proposal and move on to finalizing and reviewing its implementation (and then to cabal-install)? If in-person video meetings would help, I'd gladly organize some (also for the next stages if it's too early at this point). Thoughts, ideas? Cheers, Mikolaj

2 3

Cabal developers meeting of the 21/12/2023
by Theophile Hécate Choutri 03 Jan '24

03 Jan '24

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

1 0

Cabal developers meeting of the 24/11/2023
by Theophile Hécate Choutri 24 Nov '23

24 Nov '23

## 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-… . 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#st… )? - 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… - 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.

1 0

Cabal developers meeting of the 09/11/2023
by Theophile Hécate Choutri 10 Nov '23

10 Nov '23

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

1 0

Cabal-install 3.10.2.0 released
by Theophile Hécate Choutri 06 Nov '23

06 Nov '23

Dear all, cabal-install 3.10.2.0 has been released and is available in ghcup as well as on downloads.haskell.org <https://downloads.haskell.org/cabal/cabal-install-3.10.2.0/>. 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.… You can join the Cabal development community on Matrix at #hackage:matrix.org <https://app.element.io/#/room/#hackage:matrix.org> Cheers, Hécate

1 0

Cabal developers meeting of the 26/10/2023
by Theophile Hécate Choutri 27 Oct '23

27 Oct '23

## Current Affairs (tickets and PRs of interests) * Use response files for ghc invocations #9367: https://github.com/haskell/cabal/pull/9367 * PackageInfo functionality is not guarded behind cabal-version. #9331 : https://github.com/haskell/cabal/issues/9331 * We have to be more careful in the future to guard new functionality behind the cabal-version field of the file format. * Terminology: Internal libraries are out, sublibraries are in! This is the terminology that was already used in several blog posts, and as such we must unify the vocabulary: https://github.com/haskell/cabal/pull/9371 * The exact-print parser topic has been raised from the dead once again, and the situation is that many people seem to be interested in pursuing experiments that cannot be realistically included in the cabal parsing infrastructure. Due to the extreme sensitivity of the subject, a proposal will have to go through the Technical Working Group before it's approved, so that development can be smoother. * lib:Cabal 3.10.2.1 has been released, with relaxed restrictions on the contents of the c-sources stanza in the cabal file format. ## Summer of Code 2023 Suganya has landed the last PR to convert cabal errors to error codes. Further documentation work is needed but the main goal has been reached. Congratulations Suganya! ## Food for thought Hécate: Bodigrim suggests that 3.10 could be kept on life support in order to provide interfaces that we are trying to get rid of (namely v1- commands, Custom setups, etc). See original comment: https://github.com/haskell/cabal/pull/9107#issuecomment-1773927473 *Conclusion: It's been decided that this would be too burdensome, and we lack the resources to do such a thing.*

1 0

Cabal developers meeting of the 26/10/2023 agenda and minutes
by Theophile Hécate Choutri 22 Oct '23

22 Oct '23

Hi everyone, in advance here are the minutes of our bi-monthly meeting: https://hackmd.io/@Hecate/HJI186-fa/edit I urge everyone to add their topic of interest, if only to go back to the topics that we discussed during the previous meeting, like the project unit ID in the path, the hooks proposal, etc. See you next week, Hécate

1 0

Cabal developers meeting of the 12/10/2023
by Theophile Hécate Choutri 13 Oct '23

13 Oct '23

Hi everyone, here are the minutes of today's meeting. Due to the poor quality of the Jitsi service at the time, the meeting was held on Google Meet. ## Cabal 3.10.2.0 status Distribution blockers: * Windows paths corrupted in CI -> https://github.com/haskell/ghcup-metadata/pull/127 * error: https://github.com/haskell/ghcup-metadata/pull/127#issuecomment-1742107642 ( https://github.com/haskell/ghcup-metadata/actions/runs/6371387038/job/17293… ) * Julian has some steps to bypass this blocker. In any case we need more in-house expertise. * No i386 Alpine bindists produced anymore since last release * We should deprioritise i386 as GHC is far from being reliable on this platform, and statically linking GHC doesn't work. ## Current Affairs ### Hooks build type https://github.com/haskell/cabal/issues/9292 now has a design document that you can read: https://github.com/well-typed/hooks-build-type/blob/main/design.md. An accompanying survey is also available at https://github.com/well-typed/hooks-build-type/blob/main/survey.md that justifies the decisions. Artem: would it be possible to post it on Discourse / Cafe? Hécate: It will be considered, and will be done. ### Inclusion of project unit identifier in store paths and compiler ABI tag in package hashes Simon Hengel (_sol_) opened two PRs of interest: * [Include the compiler ABI tag in nix-style package hashes #9325]( https://github.com/haskell/cabal/pull/9325) * [Include the GHC "Project Unit Id" in the cabal store path #9326]( https://github.com/haskell/cabal/pull/9326) To fix https://github.com/haskell/cabal/issues/8114 Ben is not very convinced of this design, because it hampers reinstallable GHC from being implementable. You'd want to track GHC like any other build tool, and not have it intervene in distinguishing store items. Gershom prefers inserting the disambiguation hash in the path, as it does not lead to weird situations in terms of cohabitation. ### Improving Cabal docs Can people look into: https://github.com/haskell/cabal/pull/9212 where a volunteer is trying to improve the getting started section of the manual? It's easy to make it worse. We need to have more eyeballs on it.

1 0

Cabal developers meeting of the 28/09/2023
by Theophile Hécate Choutri 29 Sep '23

29 Sep '23

Hi everyone, here are the minutes of today's meeting: ## 3.10.2.0 Release The release has been cut and we will dogfood it for a short while. The binaries are uploaded at https://downloads.haskell.org/~cabal/Cabal-3.10.2.0/ and are being integrated into ghcup. An official announcement will be sent on October 9th, along with the GHC 9.8 release. You are encouraged to try it out. Each archive contains a binary and the plan file generated by the build system. ## Bad paths on Windows https://github.com/haskell/cabal/issues/9253 has been merged, although short of replacing FilePath with OsPath, there will always be the possibility of other problems. ## Setup.hs The effort to give a better alternative to custom Setup.hs is reviving. The problematic generality of the current mechanism is the main source of pain. This produces much complexity (as in "it is hard to determine outputs from known inputs"). ## Misc Hécate: It would be nice to take some time and think about how GHC and cabal have evolved during the last decades, and how with the consolidation of the ecosystem, different boundaries could be drawn. Some code paths and concerns could migrate from one tool to the other. Ben: We have a cabal specification; I wish we'd kept that up to date; I think that would define the interface between cabal & ghc and other implementations. Gershom: Code as spec would be a good solution. Hécate will probably spend some time on refitting the dump-decls tool made for GHC release engineering to something more standalone (perhaps integrated in cabal-install?)

1 0

Cabal developers meeting of the 14/09/2023
by Theophile Hécate Choutri 15 Sep '23

15 Sep '23

Hi everyone, here are the minutes of today's meeting: ## 3.10.2.0 Release * PVP breakage: https://github.com/haskell/cabal/issues/9258 * This raises the question of keeping the GHC Extensions list inside Cabal. We do not perform sanity checking beyond saying "Unknown extension". * Brandon suggests that `ghc --supported-languages` could be used by Cabal * The list was added for the solver to pick packages, although Mikołaj reports that GHC gets queried at run-time by Cabal. * Gershom: long-term we should have a GHC feature with a pragma that declares non-exaustive pattern matches https://doc.rust-lang.org/reference/attributes/type_system.html * Something for the Stability WG * We postpone the removal of the GHC extensions list for now. * Action item: Hécate can revert https://github.com/haskell/cabal/pull/9028 and https://github.com/haskell/cabal/commit/9faa4db9180ec4a645cfa1a4a00666dcaf3… ## Bad paths on Windows Brandon found a problem when generating short path names. The problem takes root at the Arbitrary instance of InstallDirs. Unsafe on both Windows and POSIX, because it's relying on the Arbitrary instance of String. See https://github.com/haskell/cabal/issues/9253 ## Misc * Token auth for Hackage is making good progress: https://github.com/haskell/cabal/pull/9058 * Big up to David Binder for the documentation work

1 0