ghc 9.0.1

[carlocab]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

ghc 9.0 only works with cabal-install 3.4 or later [1]. However, the latest stable release of cabal-install is 3.2. I've added a [email protected] formula and switched all the formulae that use it to [email protected].

I omitted revision bumps where [email protected] is a build-only dependency.

Closes #70475.
Closes #70591.

[1] https://www.haskell.org/ghc/download_ghc_9_0_1.html

[carlocab]

ghc 9.0.1 doesn't suit as a replacement for ghc 8.10.4. None of the formulae that depend on ghc build with ghc 9.0.1, and ghc 9.0.1 doesn't even work with our cabal-install.

I think most users of ghc would therefore likely keep using [email protected] as the primary ghc formula, so I'm reluctant to make [email protected] keg-only. I've instead put appropriate conflicts_with stanzas in ghc and [email protected], which can be made keg-only when ghc 9.x.y works well enough as a replacement.

Thoughts/objections, @homebrew/core?

[SMillerDev]

I think we should follow our standards. Despite it being inconvenient right now, it is what users expect from homebrew. The caveats will tell users what to do.

[MikeMcQuaid]

@carlocab versioned formulae should never conflict with each other. Either one or none of the versions should not be keg_only. In this case I think we have two options:

• make [email protected] keg_only :versioned as usual and upgrade ghc to 9
• leave ghc as is and add a new keg_only :versioned ghc@9 formula that people can use until we're ready to switch over the default (this is my recommendation)

[MikeMcQuaid]

versioned formulae should never conflict with each other.

we/I should probably add documentation and/or audits to ensure this is the case.

[carlocab]

leave ghc as is and add a new keg_only :versioned ghc@9 formula that people can use until we're ready to switch over the default (this is my recommendation)

This sounds good to me. Thanks Mike.

[MikeMcQuaid]

Another option for formulae like this where this becomes a repeated problem is we get rid of ghc.rb entirely in favour of [email protected] and ghc@9 so we can do a gradual migration. We did this for Python and OpenSSL.

[carlocab]

we/I should probably add documentation and/or audits to ensure this is the case.

I think there is an audit for this. There's also an allowlist, but that's practically empty at the moment. Though I guess the ideal is that it's empty, rather than almost empty.

Another option for formulae like this where this becomes a repeated problem

I'm not sure we're in repeated-problem territory yet. ghc is also more manageable than python or openssl, since it has only a few dozen dependencies, rather than a few hundred.

[carlocab]

Only one failure on the Intel nodes: cryptol

Tested this on GitHub nodes running Catalina and Big Sur, but building with the existing ghc formula: carlocab/homebrew-personal#36

Same failure.

[carlocab]

cryptol failure reported upstream at GaloisInc/cryptol#1083.

[carlocab]

Upstream confirmed that the failure isn't due to the version bump. This is blocking another PR (#70750), so I'm merging this one and fixing the cryptol source build in a separate PR. cryptol should have working bottles at the moment anyway.

[BrewTestBot]

@carlocab has triggered a merge.