- cabal-devel - Haskell.org

GSoC Project Ideas
by Aaron Allen 24 Jan '25

24 Jan '25

Dear Cabal Devs, We are seeking project ideas for Google Summer of Code 2025! See https://summer.haskell.org/ideas.html for instructions on submitting a project idea, the deadline to submit an idea is Feb 10th. Thanks, Aaron

1 0

Re: Is Cabal a core library?
by Mikolaj Konarski 08 Nov '24

08 Nov '24

Hi Andrew, We discussed this on the list and on today's cabal devs meeting and we are grateful for the proposal and we don't only accept it, but we'd like to ask you to consider all cabal packages (`Cabal`, `Cabal-syntax`, `cabal-install` and `cabal-install-solver`) as core packages. They don't really make much sense without each other and while only two of them are GHC boot packages, if I'm not mistaken, we posit they are all core packages of the Haskell ecosystem. Cheers, Mikolaj On Thu, Nov 7, 2024 at 12:11 AM Andrew Lelechenko <andrew.lelechenko(a)gmail.com> wrote: > > Hi Mikolaj, > > Just a gentle ping, did you come to a conclusion on this? > (I’m not on cabal-devel mail list) > > Best regards, > Andrew > > > On 30 Oct 2024, at 09:03, Mikolaj Konarski <mikolaj(a)well-typed.com> wrote: > > > > In fact, I'm not sure you are on the cabal-devel list, so I should > > have added you to CC of this email. > > > > ---------- Forwarded message --------- > > From: Mikolaj Konarski <mikolaj(a)well-typed.com> > > Date: Wed, Oct 30, 2024 at 9:59 AM > > Subject: Fwd: Is Cabal a core library? > > To: <cabal-devel(a)haskell.org> > > > > > > Andrew, thank you for your kind offer. > > > > Let me forward this to other Cabal developers. > > > > Best regards, > > Mikolaj > > > > ---------- Forwarded message --------- > > From: Andrew Lelechenko <andrew.lelechenko(a)gmail.com> > > Date: Wed, Oct 30, 2024 at 1:50 AM > > Subject: Is Cabal a core library? > > To: Mikolaj Konarski <mikolaj(a)well-typed.com>, Hécate <hecate(a)glitchbra.in> > > > > > > Hi Mikolaj and Hecate, > > > > There is a push to consolidate notions of boot (= needed to build GHC) > > and core (= under CLC aegis) libraries, so that critical parts of > > Haskell ecosystem are more resilient. How do you feel about > > designating `Cabal` and `Cabal-syntax` as core packages? > > > > While at the moment Cabal has a very healthy team (thanks a ton for > > your work!), there were moments in Cabal history when things were > > drastically different. So having an additional safety net, such that > > CLC is able to provide additional / emergency maintenance, could be > > helpful in future. > > > > Designating a library as a core package does not impose much change on > > day-to-day operations. CLC does not interfere with daily development > > of Core Libraries as long as appointed maintainers keep them in an > > appropriate shape and support healthy communication with contributors. > > You can find the full policy at > > https://github.com/haskell/core-libraries-committee?tab=readme-ov-file#core… > > > > (Feel free to forward to other Cabal developers) > > > > Best regards, > > Andrew >

2 1

Re: Your vision for the future of Cabal subsystems
by sebright2 05 Nov '24

05 Nov '24

Here are my main goals for the dependency solver: - Finish implementing per-component dependency solving: https://github.com/haskell/cabal/issues/4087 - Improve performance in the case where there are many dependencies, especially setup and build tool dependencies, but not many conflicts. It would solve issues like https://github.com/haskell/cabal/issues/6309 and make freeze files more useful. - Improve error messages when there is no solution. In simple cases, we might be able to use heuristics (or even an LLM as Artem suggested) to highlight the most important conflicts or suggest solutions. I'd also like the message to focus more on the final conflict set than on the first conflicts encountered, which would help in more complex cases. - Try to find better solutions or make solutions more stable. The solver could also give suggestions on how to improve the solution, such as how to loosen constraints in order to avoid deprecated versions. - Improve documentation of the algorithm. -Kristen > Hi everyone, > > I'd like to ask the people who have been working, are involved or are > dependent on any subsystem of the Cabal project to take some time and think > about what they would like to see for the future. More directly, I would > like to ask you to dream about the future. Don't concern yourself with > implementation, energy or resources, but rather about the direction, and > the shape of the subsystems that you have a stake in. > Things like the solver, the UX of such and such sub-command, performance of > a certain use-case, targeting a certain demographic, a change in how we get > feedback from end-users… > > This will help us with coming up with a product vision that will serve as a > backbone for the immediate and near-future development of cabal. I > understand most of us do this in our free time, but that does not make us > illegitimate to wish for better things, especially when we are involved in > the long run. > > See you all on Matrix and during our bi-monthly meeting. > > Cheers, > Hécate

1 0

Your vision for the future of Cabal subsystems
by Theophile Hécate Choutri 01 Nov '24

01 Nov '24

Hi everyone, I'd like to ask the people who have been working, are involved or are dependent on any subsystem of the Cabal project to take some time and think about what they would like to see for the future. More directly, I would like to ask you to dream about the future. Don't concern yourself with implementation, energy or resources, but rather about the direction, and the shape of the subsystems that you have a stake in. Things like the solver, the UX of such and such sub-command, performance of a certain use-case, targeting a certain demographic, a change in how we get feedback from end-users… This will help us with coming up with a product vision that will serve as a backbone for the immediate and near-future development of cabal. I understand most of us do this in our free time, but that does not make us illegitimate to wish for better things, especially when we are involved in the long run. See you all on Matrix and during our bi-monthly meeting. Cheers, Hécate

4 4

Fwd: Is Cabal a core library?
by Mikolaj Konarski 31 Oct '24

31 Oct '24

Andrew, thank you for your kind offer. Let me forward this to other Cabal developers. Best regards, Mikolaj ---------- Forwarded message --------- From: Andrew Lelechenko <andrew.lelechenko(a)gmail.com> Date: Wed, Oct 30, 2024 at 1:50 AM Subject: Is Cabal a core library? To: Mikolaj Konarski <mikolaj(a)well-typed.com>, Hécate <hecate(a)glitchbra.in> Hi Mikolaj and Hecate, There is a push to consolidate notions of boot (= needed to build GHC) and core (= under CLC aegis) libraries, so that critical parts of Haskell ecosystem are more resilient. How do you feel about designating `Cabal` and `Cabal-syntax` as core packages? While at the moment Cabal has a very healthy team (thanks a ton for your work!), there were moments in Cabal history when things were drastically different. So having an additional safety net, such that CLC is able to provide additional / emergency maintenance, could be helpful in future. Designating a library as a core package does not impose much change on day-to-day operations. CLC does not interfere with daily development of Core Libraries as long as appointed maintainers keep them in an appropriate shape and support healthy communication with contributors. You can find the full policy at https://github.com/haskell/core-libraries-committee?tab=readme-ov-file#core… (Feel free to forward to other Cabal developers) Best regards, Andrew

4 3

Fwd: [ANN] cabal-install-3.12.1.0 (and accompanying libraries) released
by Artem Pelenitsyn 28 Jun '24

28 Jun '24

Dear all, The cabal release team brings you the release of the cabal-install tool, version 3.12.1.0. This is the first release of the tool in the 3.12 series, and, hence, the first cabal-install supporting Cabal 3.12 packaged with GHC 9.10.1. We also update the three main libraries. - cabal-install: The command-line interface for Cabal and Hackage. <https://hackage.haskell.org/package/cabal-install-3.12.1.0> - Cabal: A framework for packaging Haskell software <https://hackage.haskell.org/package/Cabal-3.12.1.0> - Cabal-syntax: A library for working with .cabal files <https://hackage.haskell.org/package/Cabal-syntax-3.12.1.0> - cabal-install-solver: The command-line interface for Cabal and Hackage. <https://hackage.haskell.org/package/cabal-install-solver-3.12.1.0> The binaries for cabal-install are available on our website <https://downloads.haskell.org/cabal/cabal-install-3.12.1.0/> and can be installed via GHCup manually, e.g.: - Linux x86_64 (static, alpine3_18): ghcup --no-cache install cabal -u 'https://downloads.haskell.org/cabal/cabal-install-3.12.1.0/cabal-install-3.…' 3.12.1.0 - MacOS AArch64: ghcup --no-cache install cabal -u 'https://downloads.haskell.org/cabal/cabal-install-3.12.1.0/cabal-install-3.…' 3.12.1.0 - Windows: ghcup --no-cache install cabal -u 'https://downloads.haskell.org/cabal/cabal-install-3.12.1.0/cabal-install-3.…' 3.12.1.0 - or a similar command for your platform using the binaries provided on the website - as usual, cabal update && cabal install cabal-install-3.12.1.0 is an option too. We expect the official GHCup channel to be updated with the 3.12.1.0 binaries soon. <https://discourse.haskell.org/t/cabal-install-3-12-1-0-and-accompanying-lib…>What is new *Performance* - Significant speedups during cabal startup due to use of the latest tar *Project Organization* - Support for asm, cmm, and js sources in executable components - Support for per-component builds when coverage is enabled - Haskell files in explicit source directories take precedence over autogenerated Haskell files - Fix precedence for PATH for build-tools-depends (executables from PATH don’t shadow executables from build-tool-depends anymore) *UX* - Errors now have error codes, which will be documented on https://errors.haskell.org - A new subcommand, cabal path, which can be used to get information about the paths cabal will use within a project - Support for authentication tokens for uploading to Hackage - --(test-)show-details=direct is now the default - Shorten solver rejection messages by removing repetition - Show provenance of project constraints *Interaction with GHC* - Support for loading multiple components into one repl session - Support for the --semaphore flag to enable interaction with GHC Job Server protocol - Support for GHC2024 - Support for language extensions ExtendedLiterals¸ ListTuplePuns, and TypeAbstractions *Other Compilers* - Micro Haskell (MHS) has been added as a known compiler. We don’t have support for driving it yet, though. See the release notes <https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.…> for more details and other changes. <https://discourse.haskell.org/t/cabal-install-3-12-1-0-and-accompanying-lib…> Contributors 50^2, Adam Gundry, Andrea Bedini, Andreas Abel, Andreas Klebinger, Arjun Kathuria, Artem Pelenitsyn, BasLaa, Bas Laarakker, Ben Gamari, Bodigrim, Brandon Chinn, brandon s allbery kf8nh, Bryan Richter, Colton Clemmer, Csaba Hruska, cydparser, Daniel Trstenjak, David Binder, David Christiansen, Edwin Marshall, Elodie Lander, Erik de Castro Lopo, Felix Yan, fendor, Finley, Francesco Ariis, Francesco Gazzetta, Fraser Tweedale, Gershom Bazerman, Hamish Mackenzie, Hécate Moonlight, Ikko Eltociear Ashimine, Jana Chadt, Javier Sagredo, Jean-Paul Calderone, Jens Petersen, Jessica Hamilton, John Paul Adrian Glaubitz, Josh Meredith, Julia Longtin, Julian Ospald, Kazuki Okamoto, Kristen Kozak, Krzysztof Gogolewski, liamzee, Liisi Kerik, Lin Runze, Malte Neuss, malteneuss, Marcin Szamotulski, Matthew Pickering, Mel Zuser, Michael Peyton Jones, Mike Pilgrem, Mikolaj Konarski, mixphix, Oleg Grenrus, Ondřej Šebek, Patrick Augusto, Patrick Dougherty, Peter Becich, Phil de Joux, Pierre Le Marre, Rebecca Turner, Rodrigo Mesquita, Ryan Scott, Samuel Thibault, Sander, Sebastian Tee, Sergey Vinokurov, Shae Erisson, sheaf, Simon Hengel, Siyuan Chen, Sören Tempel, SuganyaAK, Suganya Raju, Sylvain Henry, Taylor Fausak, Teo Camarasu, Tom Ellis, tomjaguarpaw, Tommy Bidne, Tom Smeding, Torsten Schmits, Tristan Cacqueray, Troels Henriksen, Wismill, Yvan Sraka, Zoe Zuser We thank all contributors as well as our reviewers, QA testers, devops, and others without whom this release wouldn’t be possible. <https://discourse.haskell.org/t/cabal-install-3-12-1-0-and-accompanying-lib…> Feedback Please, report any issues you notice with the 3.12.1.0 release on our GitHub: https://github.com/haskell/cabal — cabal release team (Artem, Brandon, Francesco, Gershom, Hécate, Mikołaj)

1 0

[ANN] Cabal 3.12 released
by Francesco Ariis 08 May '24

08 May '24

Dear cafe, Cabal team is happy to announce the release of `Cabal` the library version `3.12.0.0` and the companion pre-release of `cabal-install` (the commandline tool; scroll down for more information). ## What is new? There are a number of new features in this release (`Cabal`) and pre-release (`cabal-install`), such as: - Add support for `asm`, `cmm`, and `js` sources in executable components. - Add `--haddock-output-dir` flag to `cabal haddock`. - Add `--semaphore` option to `./Setup build` interface. - Add `--promised-dependency` flag to `./Setup configure` interface. - Add the ability to `--ignore` specific checks to `cabal check`. - Add support for `GHC2024` language edition. - Add support for loading multiple components into one repl session (especially important for HLS users). - Add `cabal path` command. - Add support for authentication tokens for uploading to Hackage. - Allow more flags in the init section of config file. - Add `--semaphore` flag to enable interaction with GHC Job Server protocol. - Adds functionality for the `--offline` flag with the `build` command. - Improve solver rejections in brevity and accuracy. There is much more: for a detailed list of enhancements, changes, and bugfixes, please check the Cabal-3.12.0.0 changelog [1] (and the cabal-install 3.12.0.0-prerelease changelog [2]. [1] https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.12.0.0.md [2] https://github.com/haskell/cabal/blob/master/release-notes/WIP-cabal-instal… ## Authors and contributors Cabal is a collaborative effort; these people contributed with code to this release: aleeusgr Adam Gundry Andrea Bedini Andreas Abel Andreas Klebinger Arjun Kathuria Artem Pelenitsyn BasLaa Bas Laarakker Ben Gamari Bodigrim Brandon Chinn Brandon S. Allbery Bryan Richter Colton Clemmer Csaba Hruska cydparser Daniel Trstenjak David Binder David Christiansen Edwin Marshall Elodie Lander Erik de Castro Lopo Felix Yan Fendor Finley Francesco Ariis Francesco Gazzetta Fraser Tweedale Gershom Bazerman Hamish Mackenzie Hécate Moonlight Ikko Eltociear Ashimine Jana Chadt Javier Sagredo Jean-Paul Calderone Jens Petersen Jessica Hamilton John Paul Adrian Glaubitz Josh Meredith Julia Longtin Julian Ospald Kazuki Okamoto Kleidukos Kristen Kozak Krzysztof Gogolewski liamzee Liisi Kerik Lin Runze malteneuss Malte Neuss Marcin Szamotulski Matthew Pickering Mel Zuser Michael Peyton Jones Mike Pilgrem Mikolaj Konarski mixphix Oleg Grenrus Ondřej Šebek Patrick Augusto Patrick Dougherty Phil de Joux Pierre Le Marre Rebecca Turner Rodrigo Mesquita Ryan Scott Samuel Thibault Sander Sebastian Tee Sergey Vinokurov Shae Erisson sheaf Simon Hengel Siyuan Chen Sören Tempel Suganya Raju Sylvain Henry Taylor Fausak Teo Camarasu Tom Ellis Tom Smeding Torsten Schmits Tristan Cacqueray Troels Henriksen Wismill Yvan Sraka The release could not be done without the help of the manual QA team and devops people, we thank them both. Thanks also to the many users who provided bug reports and suggestions for improvements. A special mention to Hécate, who recently stepped down from Cabal release coordination and left the process in a better, more organised shape than what was before. ## How to get the `cabal-install` pre-release This release is a Cabal-the-library release, but if you want to test the new features of `cabal-install`, you can download the pre-release of the commandline tool via GHCup. Use one of the following commands, depending on your OS: ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848320/artifacts/raw/out/c…' 3.12.0.0-prerelease ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848326/artifacts/raw/out/c…' 3.12.0.0-prerelease ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848327/artifacts/raw/out/c…' 3.12.0.0-prerelease or an analogous command for any other of the artifacts produced by the [pre-release pipeline](https://gitlab.haskell.org/haskell/cabal/-/pipelines/93759). ## How to help? Cabal is a complex piece of software running on many different machine. Two easy ways to help the development team producing quality releases are: - Join the manual QA team - Test nightly binary `cabal-install` snapshots and pre-releases (such as the 3.12.0.0 pre-release mentioned above) and report any problem you find. [3] https://discourse.haskell.org/t/manual-qa-for-cabal-install/6225

1 0

Re: GSoC mentor for cabal vulnerability check
by Gershom B 07 Mar '24

07 Mar '24

Hi aaron! ccing the cabal-devel list on this. -g On Tue, Mar 5, 2024 at 10:35 AM Aaron Allen <aaronallen8455(a)gmail.com> wrote: > > Hi Gershom, > > I'm looking for a mentor for the cabal vulnerability check project (https://summer.haskell.org/ideas.html#cabal-audit-vulnerable-dependencies) Do you know of anyone who might be willing and able? > > Thanks, > Aaron

1 0

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

11 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