From mikolaj at well-typed.com  Thu Aug 11 23:04:52 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Fri, 12 Aug 2022 01:04:52 +0200
Subject: Just released: cabal 3.8.1.0
Message-ID: <CAHFo2uoJScNJYzum4d2BO0QbCiH8WxAphrw+2uddb0y2hwcG3w@mail.gmail.com>

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.

From mikolaj at well-typed.com  Sun Aug 28 19:19:30 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Sun, 28 Aug 2022 21:19:30 +0200
Subject: [Haskell-cafe] With cabal.project, what's the story about warning
 and -Werror compiler flags?
In-Reply-To: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be>
References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be>
Message-ID: <CAHFo2upfxV5EtP2JNFnGTK_+WCWOTh3oWZ289tu7WUMkAOkEGw@mail.gmail.com>

Let me CC to cabal-devel at haskell.org.

On Sun, Aug 28, 2022 at 3:39 PM Nicolas Trangez <ikke at 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.

From mikolaj at well-typed.com  Mon Aug 29 04:58:07 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 29 Aug 2022 06:58:07 +0200
Subject: [Haskell-cafe] With cabal.project, what's the story about warning
 and -Werror compiler flags?
In-Reply-To: <CAHFo2upfxV5EtP2JNFnGTK_+WCWOTh3oWZ289tu7WUMkAOkEGw@mail.gmail.com>
References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be>
 <CAHFo2upfxV5EtP2JNFnGTK_+WCWOTh3oWZ289tu7WUMkAOkEGw@mail.gmail.com>
Message-ID: <CAHFo2upryGwM72GH2yng1w1iFDcNL4pw6VdoAvMp9JNOsZCG3Q@mail.gmail.com>

Hi Nicolas,

> Before, I put compiler warning flags like `-Wall` in `Ghc-Options`
> ..
> 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.

They'd be certainly out of place in a binary package. However,
a source package is meant to be compiled, so instructing
the compiler to produce warnings during compilation seems relevant.
A related reason is that IIRC haskell-ci does `cabal sdist` and then
runs all its operations based on the resulting source package.
So, if you want to see warnings in CI logs, you need to retain
the relevant instruction in the source package created by `cabal sdist`.
And warnings sometimes help to explain why compilation fails
or why the resulting binary misbehaves.

> > 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?

That sounds like a bug. Is there anything relevant in the issue tracker?

All the best,
Mikolaj

From mikolaj at well-typed.com  Mon Aug 29 09:53:38 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 29 Aug 2022 11:53:38 +0200
Subject: [Haskell-cafe] With cabal.project, what's the story about warning
 and -Werror compiler flags?
In-Reply-To: <CAHFo2upryGwM72GH2yng1w1iFDcNL4pw6VdoAvMp9JNOsZCG3Q@mail.gmail.com>
References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be>
 <CAHFo2upfxV5EtP2JNFnGTK_+WCWOTh3oWZ289tu7WUMkAOkEGw@mail.gmail.com>
 <CAHFo2upryGwM72GH2yng1w1iFDcNL4pw6VdoAvMp9JNOsZCG3Q@mail.gmail.com>
Message-ID: <CAHFo2uqkSiSkJNFJrnrKvMU5s--kGQXfxKmrHQWzfsct1O_mYA@mail.gmail.com>

Another angle is that cabal.project is for a set of packages
and foo.cabal is for an individual package foo.
That distinction would suggest cabal.project is only for compiler
options that affect all packages in the project.
However, with 1-package projects, this is a moot point.

OTOH, given that Hackage does not accept package collections,
but only individual packages, and this is how packages
are compiled as dependencies, all packages (or at least all
libraries) need to be ready to behave like 1-package projects
even bereft of cabal.project files. (BTW, I wonder, perhaps Hackage
should accept package collection for non-libraries, that is,
for packages that are not intended solely to be dependencies
of other packages.) Perhaps putting in cabal.project only what
is not needed for the use as a dependency of another package
makes sense. E.g., only the options affecting executable
components of the packages.

On Mon, Aug 29, 2022 at 6:58 AM Mikolaj Konarski <mikolaj at well-typed.com> wrote:
>
> Hi Nicolas,
>
> > Before, I put compiler warning flags like `-Wall` in `Ghc-Options`
> > ..
> > 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.
>
> They'd be certainly out of place in a binary package. However,
> a source package is meant to be compiled, so instructing
> the compiler to produce warnings during compilation seems relevant.
> A related reason is that IIRC haskell-ci does `cabal sdist` and then
> runs all its operations based on the resulting source package.
> So, if you want to see warnings in CI logs, you need to retain
> the relevant instruction in the source package created by `cabal sdist`.
> And warnings sometimes help to explain why compilation fails
> or why the resulting binary misbehaves.
>
> > > 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?
>
> That sounds like a bug. Is there anything relevant in the issue tracker?
>
> All the best,
> Mikolaj

From mikolaj at well-typed.com  Tue Aug 30 13:18:08 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Tue, 30 Aug 2022 15:18:08 +0200
Subject: [Haskell-cafe] With cabal.project, what's the story about warning
 and -Werror compiler flags?
In-Reply-To: <27c0ed3a3128f592f7cfc117db23c860480b31de.camel@nicolast.be>
References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be>
 <CAHFo2upfxV5EtP2JNFnGTK_+WCWOTh3oWZ289tu7WUMkAOkEGw@mail.gmail.com>
 <CAHFo2upryGwM72GH2yng1w1iFDcNL4pw6VdoAvMp9JNOsZCG3Q@mail.gmail.com>
 <27c0ed3a3128f592f7cfc117db23c860480b31de.camel@nicolast.be>
Message-ID: <CAHFo2upg4_gFS8d=z7hvbpFsMU4LdffMB+Ntb5FXFK9m8TYsHQ@mail.gmail.com>

> 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. :)

From a.pelenitsyn at gmail.com  Wed Aug 31 22:18:30 2022
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Wed, 31 Aug 2022 18:18:30 -0400
Subject: Fwd: Interview request // Mergify
In-Reply-To: <2b0b5332-8611f986-1661864766-193425700012073@mergify.intercom-mail-140.com>
References: <2b0b5332-8611f986-1661864766-193425700012073@mergify.intercom-mail-140.com>
Message-ID: <CAPKAvQVeZpYCtzPURho3fQ-ZVt+axvDXZcb0swxhr0XPoNKOsw@mail.gmail.com>

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 at mergify.com>
Date: Tue, 30 Aug 2022 at 09:06
Subject: Interview request // Mergify
To: <a.pelenitsyn at 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%2FzfNGYuEjCMJfY6c3akW%2FnFOAA0leOabk5B6cAEtocjrIOpe0ejCI1%2BCvQKzxEBTbKLUYew%3D%3D&h=6b90d2b671c492cb0978d95015b76affd64d9f9e-hrdyfmji_193425700012073>
- [This is my workflow series]
https://blog.mergify.com/this-is-my-workflow-elastic/
<https://mergify.intercom-clicks.com/via/e?ob=g2JjGZB%2F%2FxJyvpPoOvH5xwDlnbKSt2Hf889yiCXn3G%2B4P%2FDEKYJVEnPRe%2BC49bGlhZNejNhijnAlyOZOXHrNdw%3D%3D&h=3387339b03fb1ef63a09af6a8f885eed93e233ce-hrdyfmji_193425700012073>

Is that something you might be interested in?"

Have a great day
  *Mergify Support*
[image: intercom]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20220831/2afea52c/attachment.html>