- cabal-devel - Haskell.org

Data constructor of VersionIntervals not exported
by Daniel Trstenjak 16 May '23

16 May '23

Hi, I'm trying to update my tool cabal-bounds[1] to the newest version of the Cabal library. My tool needs to convert a [VersionInterval] into a VersionRange, which currently doesn't seem to be possible, because the data constructor of VersionIntervals isn't exported from Distribution.Types.VersionInterval. Best regards, Daniel Trstenjak [1] https://github.com/dan-t/cabal-bounds

3 3

Code Review in Cabal Project
by Artem Pelenitsyn 08 May '23

08 May '23

Dear Cabal team, I have a couple points on the multiple components PR (https://github.com/haskell/cabal/pull/8726) drama. I didn't want to spend everyone's time during the meeting, and you can decide if you want to hear more about it now. The whole discussion on the meeting (with one exception) sounded to me like we're scolding Francesco (@fgaz). I feel bad because of that. Hence my email. By the way, one exception imo is Mikolaj saying that the whole story is his responsibility too. Thank you Mikolaj! I should say that me commenting on red CI probably added to the heat that was already there, and therefore it's also my responsibility. I'm sorry that the contributor got frustrated. That said, I want to say a big THANK YOU to Francesco. You left high-quality feedback, that myself (and I think others) can learn from. I personally lack the kind of expertise that you applied when doing this review. Please, do this more often! (time permitting, of course) People keep asking (1) why this happened (contributor throwing hands in the air and seemingly abandoning PR) and how to avoid this in the future (2). I don't feel qualified to answer (1), and I think no one should try to play contributor's therapist (unless, of course, you have the education and licence for that). I don't believe any professional boundaries were crossed or something unreasonable happened. Not from Cabal team's (including Francesco) side, at least. All the requests were fair and polite requests advocating for improving quality of Cabal's code base -- the very code base we interact a lot with, and quality of which we should try to improve. My answer to (2) -- you won't be able to avoid it in the future. Unless, of course, you are willing to abolish the code review process altogether. It really depends on a contributor and whether they are able to sustain the scrutiny of the process. And you can't control that. The response shouldn't be to lower the bar for the process imo. It is my opinion that the biggest improvement to the future of Cabal would be to get more high-quality feedback for contributions, not less. Thank you, Francesco, again! -- Kind Regards, Artem

3 4

Manual QA process for cabal-install PRs
by Theophile Hécate Choutri 06 Apr '23

06 Apr '23

Hi everyone, this announcement is especially relevant to you if you contribute to cabal-install. To reduce the amount of bad surprises that we get after each release, a manual QA process is being set up so that more eyes may look at some of the more user-facing changes that are introduced in cabal-install. In addition to the incentive to add QA Notes that is being added to relevant PRs (https://github.com/haskell/cabal/pull/8886) I have created a kanban board that aggregates tickets and PRs being tagged for manual QA <https://github.com/orgs/haskell/projects/3/views/1>. The idea is that we can onboard volunteers who will compile cabal-install any time after the contribution has been merged, and will test the described workflow to see if it holds, in real-life conditions, and certainly with external factors at play that will help us gather valuable feedback on the behaviour of cabal-install. Speaking of feedback, please do not hesitate to show scepticism or support regarding this initiative. I'm always happy to be able to discuss such things between stakeholders. Cheers, Your lovely release manager, Hécate

1 0

Just released: cabal 3.10.1.0
by Mikolaj Konarski 13 Mar '23

13 Mar '23

Dear cabal users and contributors, The cabal team is proud to announce the release of cabal 3.10.1.0. This is mainly a bugfix release, but it has some new features and enhancements as well. The thread about the release, including troubleshooting and porting discussions, is at https://discourse.haskell.org/t/just-released-cabal-3-10-1-0/5978 The changelogs and release notes are at https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.… and, if your code depends on the Cabal library, at https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.10.1.0.md Two backward (in)compatibility notes may be of particular interest: the XDG Base Directory Specification (conditionally) replacing ~/.cabal and the `--enable-documentation` option by default added to all `cabal haddock` invocations. Please look them up at the links above. Let me finish by thanking our esteemed benefactors, past and present, contributing code, devops, testing, feedback, comments. Representing these are the authors of all PRs included in the 3.10.1.0 release, honourably mentioned in the list of fame below. Abastro Alexander Biehl Alexey Radkov amigalemming Andrea Bedini Andreas Abel Andreas Klebinger Artem Pelenitsyn Ben Gamari Bodigrim Brandon Chinn Bryan Richter Byron Johnson Cheng Shao chowells79 Cmdv Colton Clemmer cydparser Daniel Gröber deltaspace0 Evgenii Akentev fendor Francesco Ariis Francesco Gazzetta Gautier DI FOLCO Georgi Lyubenov Gershom Bazerman Guillaume Genestier Hécate Moonlight Ikko Ashimine instinctive Jade Lovelace James Hobson Jan Synáček Jappie Klooster Javier Neira John Ericson Kobayashi Marcin Szamotulski Martijn Bastiaan Matthew Pickering Max Amanshauser Miezhiko Mike Pilgrem Musab Guma'a Patrick Dougherty Paweł Dybiec Pierre Le Marre Robert Vollmert Ross Paterson Saad Ahmed Sergey Vinokurov sheaf Sören Tempel Sylvain Henry Tom McLaughlin Troels Henriksen Vilius Panevėžys Vladislav Zavialov Wismill

1 0

The unofficial prerelease of cabal 3.10 is out
by Mikolaj Konarski 27 Jan '23

27 Jan '23

Hi fellow co-conspirators, Happy news! The unofficial prerelease of cabal 3.10 is out. Please install it, use it and report problems at our issue tracker at https://github.com/haskell/cabal/issues The prerelease is called cabal 3.9.0.0 and you can get it via ghcup as follows: ``` ghcup config add-release-channel https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prere… ghcup tui ``` Then enable "Show all versions" and then install and set "cabal 3.9.0.0". Alternatively, the binaries for the same four platforms are at https://downloads.haskell.org/~cabal/cabal-install-3.9.0.0/ Credits go to the narrower team, the wider team, and the XXL team that includes all the contributors, users and kind souls. Cheers, Mikolaj

1 1

Cabal 3.10 last call for contributions
by Mikolaj Konarski 17 Nov '22

17 Nov '22

Hi! Would you like cabal 3.10 to have your favourite bugfix, feature or overall spiffiness? If so, please let us help you help yourself. We are going to soft-freeze cabal 3.10 in a month or two and ship a little later, around the GHC 9.6 release date. There is still time to fix your favourite regression https://github.com/haskell/cabal/issues?q=is%3Aopen+label%3A%22regression+i… or add your high priority feature (or argue for bumping the priority of an existing ticket) https://github.com/haskell/cabal/labels/priority%3A%20high%20%3Afire%3A The friendly team of cabal maintainers is at your disposal whether you need a PR review, a design discussion in a ticket, or you just get stuck or urgently need somebody to chat to (the #hackage IRC/matrix room is open). Cabal 3.10 is going to be mostly a bugfix release, so there may or may not be a release candidate for you to try to break. However, brave people are continuously dogfooding the master branch from github artifacts (at the bottom of 'validate' CI jobs) or gitlab pipelines (more flavours, including statically linked Alpine Linux) https://gitlab.haskell.org/haskell/cabal/-/pipelines/59103 Another way you can contribute is by picking up a newcomer-labelled ticket. Yet another is triaging new tickets, e.g., via https://www.codetriage.com/haskell/cabal Don't worry if you feel you'd need to learn a lot --- cabal is a large and constantly changing system, so most of us are forgetting faster than learning. However, purity, types and tests often permit to focus, code-dive and fix or improve a hot subsystem in relative isolation. See you there, Mikolaj

1 0

Fwd: Interview request // Mergify
by Artem Pelenitsyn 02 Sep '22

02 Sep '22

Dear cabal devs, I made a "mistake" of opening an issue against Mergify's repo: https://github.com/Mergifyio/mergify/issues/5036 (It had to do with a change in our Mergify config couple month back that didn't work as we expected, but that's beside the point) Couple days after that I got the email I'm forwarding to you. They want an interview with > someone from the Haskell project about your GitHub workflow and how you use Mergify I am not a maintainer, only a casual contributor, so I think it's better be someone more intimately working on cabal development. I CC'ed people who created and updated Cabal's Mergify config, as well as our beloved release manager Mikolaj. Please, let me know if you're interested in talking with them. If not, I guess, I can try to fill these (rather big) shoes, but I'd really rather not. -- Best regards, Artem Pelenitsyn ---------- Forwarded message --------- From: Mergify Support <support(a)mergify.com> Date: Tue, 30 Aug 2022 at 09:06 Subject: Interview request // Mergify To: <a.pelenitsyn(a)gmail.com> Hello Artem, My name is Anne-Laure, and I am a Tech Editor at Mergify. I'm contacting you today because we'd like to interview someone from the Haskell project about your GitHub workflow and how you use Mergify. Examples of already published interviews can be found here: - [They use Mergify series] https://blog.mergify.com/pytorch-lightning-interview/ <https://mergify.intercom-clicks.com/via/e?ob=EUTVvg8QjhoVDcu%2FzfNGYuEjCMJf…> - [This is my workflow series] https://blog.mergify.com/this-is-my-workflow-elastic/ <https://mergify.intercom-clicks.com/via/e?ob=g2JjGZB%2F%2FxJyvpPoOvH5xwDlnb…> Is that something you might be interested in?" Have a great day *Mergify Support* [image: intercom]

2 1

Re: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags?
by Mikolaj Konarski 30 Aug '22

30 Aug '22

> I was under the impression (but could be mistaken) that Cabal doesn't > show warnings while building dependencies. I don't remember, either, and it depends on commandline options, but I think it does show the full log at least when a dependency fails to compile. > Not that I could find. I should work on a minimal reproducible test- > case and file something. Yes, thank you, please do. > - Keep warnings in package.cabal ghc-options/cc-options etc > - Add -Werror in cabal.project so things fail on dev machines > - Configure HaskellCI to have -Werror as well, given a no-warnings > policy Brutal but effective. :)

1 0

Re: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags?
by Mikolaj Konarski 29 Aug '22

29 Aug '22

Let me CC to cabal-devel(a)haskell.org. On Sun, Aug 28, 2022 at 3:39 PM Nicolas Trangez <ikke(a)nicolast.be> wrote: > > All, > > Working on some project, I was wondering about best-practices and > community standards for compiler flags now that `cabal.project` is a > thing. > > Before, I put compiler warning flags like `-Wall` in `Ghc-Options` and > `Cc-Options` in `mypackage.cabal` files. The use of `-Werror`, whilst > (IMHO) useful in development and CI was a bit more troublesome, since > having those in `package.cabal` (not under a default-disabled flag) was > frowned upon (and even not allowed by Hackage?) > > Having these options in `mypackage.cabal` always felt slightly weird, > since they are in no way required for a package to function: they're > developer options, not user/consumer options. Where `-wavx2` could be a > required `Cc-Options` setting for a package to build/function, `-Wall` > is not. > > With the advent of `cabal.project`, it seems to me this is the ideal > place to put developer flags: from what I understood, `cabal.project` > doesn't influence sdist/Hackage distribution, and hence could contain > all kind of GHC and C compiler flags that are useful during development > but not required for a package to build/function, including `-Werror` > (if desired by the project authors). > > Does this sound like a reasonable stance? > > If it is, I did run into a couple of issues getting things to actually > work. Whilst putting `Ghc-Options` in a `Package mypackage` section in > `cabal.project` seems to work, I'm unable to achieve the same resulsts > for C compiler invocations. Presumably there's a `Gcc-Options` setting > one can use (which is also generated in `cabal.project.local` by `cabal > configure --gcc-options ...`). However, in testing, it appears said > compiler optons are only passed to GCC when compiling, e.g., a HSC2HS > file, but not when compiling a C file part of a `C-Sources` setting > (whilst `Cc-Options` in `mypackage.cabal` are). > > Is there some discrepancy between what can be done from `cabal.project` > vs. `mypackage.cabal`? Is this intentional? Am I trying to accomplish > something that isn't/shouldn't be supported by Cabal in the first > place? > > Cheers, > > Nicolas > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 2

Just released: cabal 3.8.1.0
by Mikolaj Konarski 12 Aug '22

12 Aug '22

Here's the happy news. :) Let me copy below the contents of the announcement from https://discourse.haskell.org/t/just-released-cabal-3-8-1-0/4920 but, additionally, on this mailing list I'd like to personally thank Emily and Oleg who, among all the giants on whose shoulders we stand, have most directly affected 3.8.1.0 with their hearts and wisdom. Haskell community owes you big time. --- I’m proud to announce 3.8.1.0 version of Cabal the library and cabal-install the tool. It’s the fruit of concerted effort of innumerous collaborators, from users, through developers, to mentors, caretakers and administrators of our linked community and infrastructure sections. You, people, rock. This version works with the just released GHC 9.4.1 (in fact, for Windows it’s probably necessary) and is already available form GHCup and other channels. More technical details, APIs, changelogs and regressions can be found at Release cabal v3.8.1.0 · haskell/cabal · GitHub. The release is huge, so let me mention only a few random highlights: public/private sublibraries are fully supported and no longer experimental (6. Package Description — Cabal 3.8.1.0 User's Guide) you can now put in your cabal.project something like import: https://www.stackage.org/lts-18.5/cabal.config and it works (7. cabal.project Reference — Cabal 3.8.1.0 User's Guide) new Cabal-syntax and cabal-install-solver packages have been split off there’s no more confusion of compiler options for the local code and for the dependencies (https://github.com/haskell/cabal/pull/7973) one can now define code generators in test stanzas, which is one more principled step away from Custom Setups (https://github.com/haskell/cabal/pull/7688) Cabal badly needs your feedback and your contributions. Please keep them coming.

1 0