GHC 9.8

[jchia]

Describe the bug
The project is described in taffybar.cabal as having been tested with GHC 9.8.2. But apparently it does not work with GHC 9.8.2.

To Reproduce
cabal build fails because broadcast-chan does not support GHC 9.8.2:

$ cabal build
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: my-taffybar-0.1.0.0 (user goal)
[__1] trying: base-4.19.1.0/installed-c38a (dependency of my-taffybar)
[__2] trying: taffybar-4.0.3 (user goal)
[__3] next goal: broadcast-chan (dependency of taffybar)
[__3] rejecting: broadcast-chan-0.2.1.2 (conflict: base==4.19.1.0/installed-c38a, broadcast-chan => base>=4.8 && <4.19)
[__3] skipping: broadcast-chan; 0.2.1.1, 0.2.1, 0.2.0.2, 0.2.0.1, 0.2.0 (has the same characteristics that caused the previous version to fail: excludes 'base' version 4.19.1.0)
[__3] rejecting: broadcast-chan-0.1.1 (conflict: taffybar => broadcast-chan>=0.2.0.2)
[__3] skipping: broadcast-chan-0.1.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=0.2.0.2' from 'taffybar')
[__3] fail (backjumping, conflict set: base, broadcast-chan, taffybar)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, taffybar, broadcast-chan, my-taffybar
Try running with --minimize-conflict-set to improve the error message.

However, even after commenting out broadcast-chan from taffybar.cabal, cabal build inexplicably fails on tls:

[39 of 76] Compiling Network.TLS.Parameters ( Network/TLS/Parameters.hs, dist/build/Network/TLS/Parameters.o, dist/build/Network/TLS/Parameters.dyn_o )

Network/TLS/Parameters.hs:424:35: error: [GHC-39999]
    • No instance for ‘Default ValidationCache’
        arising from a use of ‘def’
    • In the ‘sharedValidationCache’ field of a record
      In the expression:
        Shared
          {sharedCredentials = mempty,
           sharedSessionManager = noSessionManager, sharedCAStore = mempty,
           sharedValidationCache = def, sharedHelloExtensions = []}
      In an equation for ‘defaultShared’:
          defaultShared
            = Shared
                {sharedCredentials = mempty,
                 sharedSessionManager = noSessionManager, sharedCAStore = mempty,
                 sharedValidationCache = def, sharedHelloExtensions = []}
    |
424 |         , sharedValidationCache = def
    |                                   ^^^
Error: [Cabal-7125]
Failed to build tls-2.1.3 (which is required by exe:taffybar from taffybar-4.0.3). See the build log above for details.

I find it inexplicable because the Default instance exists AFAICT and building tls directly from within its own project works (using https://github.com/haskell-tls/hs-tls/tree/01766fbef097537eadad26f86c74ae7e38fe3ade).

Expected behavior
cabal build just works with GHC 9.8, or tested-with be fixed. I think enabling building the project with GHC 9.8 is preferable and required sooner or later as older GHC versions become out-of-date. However, for GHC 9.8, since broadcast-chan does not work with it and appears to be practically unmaintained, replacing it with something else first is needed. I'm not sure about the considerations for which broadcast-chan was chosen over other similar packages.

Version information
Taffybar version (or git sha if building from source): d400932
GHC version: 9.8.2

[rvl]

The reason it can successfully build in CI with GHC 9.8 is that we use the nixpkgs Haskell package set, which "jailbreaks" broadcast-chan. It's the same effect as using cabal build --allow-newer=broadcast-chan.

[jchia]

I think you mean that it disregards the dependency bounds of broadcast-chan. Am I right? broadcast-chan hasn't been updated for a long time. For one thing, it prevents the use of new resource-t versions. I don't know whether that is an issue now but it may become a real issue later, for resource-t or some other dependency that taffybar may want to use. merijn/broadcast-chan#20

…

On Sun, Dec 22, 2024 at 9:17 AM Rodney Lorrimar ***@***.***> wrote: The reason it can successfully build in CI with GHC 9.8 is that we use the nixpkgs Haskell package set, which "jailbreaks" broadcast-chan. It's the same effect as using cabal build --allow-newer=broadcast-chan. — Reply to this email directly, view it on GitHub <#600 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADNBVHRSHEIMSWAXDVG5432GYHMNAVCNFSM6AAAAABREWQZPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGI4TAMJVGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rvl]

I think you mean that it disregards the dependency bounds of broadcast-chan. Am I right?

Yes, that's what I mean.

WRT the failure to build tls-2.1.3, I can't explain that either.

I have only ever tested building with tls-1.8.0.

[jchia]

Somehow, on the latest master branch without broadcast-chan, I was able to build with GHC 9.8.4 and there was no tls-related error.