Missing GHC 8.10.4

[asr]

GHC 8.10.4 is missing from https://launchpad.net/~hvr/+archive/ubuntu/ghc.

Blocking agda/agda#5185.

[RyanGlScott]

I wonder if we should do something similar to what haskell/actions does—namely, if a particular GHC release cannot be found in https://launchpad.net/~hvr/+archive/ubuntu/ghc, fall back to ghcup to install that version. I'm itching to use GHC 8.10.4 in haskell-ci myself, so this might be a quick way to achieve this.

[phadej]

Well, I hope that hvr will soon make GHC-8.10.4 and GHC-9.0.1 into his ppa.

I'm not keen maintaining separate installations methods in CI setup. If ppa becomes unmaintained, I'd rather then drop it completely in favor of ghcup. That would mean dropping old GHC version supports, but some tradeoffs have to be made, complexity cannot grow without limit.

[phadej]

BTW, I cannot find which GHC versions ghcup supports. Does anyone know where to look for them?

[RyanGlScott]

BTW, I cannot find which GHC versions ghcup supports. Does anyone know where to look for them?

Here is what ghcup reports:

$ ~/.ghcup/bin/ghcup list --tool ghc
[ Warn  ] New GHC version available: 9.0.1. To upgrade, run 'ghcup install ghc 9.0.1'
   Tool Version Tags                      Notes
✗  ghc  7.10.3  base-4.8.2.0                   
✗  ghc  8.0.2   base-4.9.1.0                   
✗  ghc  8.2.2   base-4.10.1.0                  
✗  ghc  8.4.1   base-4.11.0.0                  
✗  ghc  8.4.2   base-4.11.1.0                  
✗  ghc  8.4.3   base-4.11.1.0                  
✗  ghc  8.4.4   base-4.11.1.0                  
✗  ghc  8.6.1   base-4.12.0.0                  
✗  ghc  8.6.2   base-4.12.0.0                  
✗  ghc  8.6.3   base-4.12.0.0                  
✗  ghc  8.6.4   base-4.12.0.0                  
✗  ghc  8.6.5   base-4.12.0.0                  
✗  ghc  8.8.1   base-4.13.0.0                  
✗  ghc  8.8.2   base-4.13.0.0                  
✗  ghc  8.8.3   base-4.13.0.0                  
✗  ghc  8.8.4   base-4.13.0.0                  
✗  ghc  8.10.1  base-4.14.0.0                  
✗  ghc  8.10.2  base-4.14.1.0                  
✗  ghc  8.10.3  base-4.14.1.0                  
✔✔ ghc  8.10.4  recommended,base-4.14.1.0      
✗  ghc  9.0.1   latest,base-4.15.0.0

As far as I can tell, this information is scraped from this file.

[phadej]

So GHC-7.10.3 is the oldest. Well, that is not that bad.

[phadej]

An option would be to have either ghcup or hvr-ppa installation per generated script. But I'm strongly against having both in one.

EDIT: because when haskell-ci is updated the GHC may be installed differently. That shouldn't matter, but if it does, that would be a head scratcher.

[sjakobi]

👍 for supporting GHC installation via ghcup, even if that means restricting backward compatibility to GHC >= 7.10. :)

[RyanGlScott]

An option would be to have either ghcup or hvr-ppa installation per generated script. But I'm strongly against having both in one.

I'm not sure that we need to go that far. Why not have the ability to specify certain sources for particular GHC versions? I'm thinking of something like this:

    strategy:
      matrix:
        include:
          - ghc: 9.0.1
            source: ghcup
          - ghc: 8.10.4
            source: ghcup
          ...
          - ghc: 7.0.4
            source: ppa

This would address your concern about the version of GHC mysteriously changing when haskell-ci updates, as each version of GHC would be pinned to a particular source. The only way the source would change is by explicit user intervention.

This will become even more important in a world where haskell-ci adds Windows support, as haskell-ci would need to be able to specify a different GHC source on Windows (e.g., chocolatey) than on other operating systems.

[phadej]

@RyanGlScott recall, the workflow file is generated completely from cabal.haskell-ci and .cabal files.

So one would need to specify which versions of GHC comes from ghcup in cabal.haskell-ci. I guess I'll be fine with that.

I'm not particularly excited to have to maintain two lists of GHC versions: which are available in hvr-ppa and which in ghcup. Have anyone tried to contact Herbert about the future of his PPA?

If its future is unclear, then I'm ready (though unhappy) to pull the plug on pre-GHC-7.10.3 releases. Herberts PPA is afaik the only sane way to get these ancient releases to work on modern Ubuntus.

[phadej]

Does anyone know whether ghcup has any backup maintainers, or is it one person effort as well? I.e. is it actually any better?

[RyanGlScott]

So one would need to specify which versions of GHC comes from ghcup in cabal.haskell-ci. I guess I'll be fine with that.

If you want to use different sources for different versions of GHC, then yes. For many projects, I could imagine just having haskell-ci pick a default source, and leaving it up to users if they want to override it. This would avoid the need for haskell-ci to manually track which versions of GHC are available in which sources, which seems like a needlessly tiresome maintenance task.

If its future is unclear, then I'm ready (though unhappy) to pull the plug on pre-GHC-7.10.3 releases. Herberts PPA is afaik the only sane way to get these ancient releases to work on modern Ubuntus.

I worry that if we don't have the ability to specify multiple sources, then we'll end up in a situation where it becomes impossible to maintain a working CI setup for projects like base-orphans, where support for older GHC versions is a must.

[phadej]

haskell-ci does track which GHC versions are available in hvr-ppa. If we add another source we will need to track which are available there.

An alternative is to trust tested-with and issue apt-get commands blindly based on them. And have a user specify wherefrom GHC is installed. (Then ranges in tested-with won't work, only == exactversion points). That means no diagnostics if tested-with contains a version of GHC which isn't available anywhere.

[phadej]

where support for older GHC versions is a must.

is it?

Maybe it should have manual CI setup then. Why make haskell-ci more complex if only few packages need it. We support old GHCs because it is easy to. If that becomes problematic (Recall, there is no GHC-7.x for focal = ubuntu 20.04 LTS in hvr-ppa atm either, almost a year old distribution), then is the cost justified?

[RyanGlScott]

is it?

Yes. base-orphans is meant to build against older versions of GHC, and therefore, it should test those versions in CI. We could just not test those versions in CI at all, but I don't consider that an acceptable solution.

Maybe it should have manual CI setup then.

To be clear, I recognize the fact that most packages will only use the latest versions of GHC, and that configurations like base-orphans are the minority. To that end, I support making the user experience with newer GHCs the best, and I'm willing to use github-patches in the event that I need to apply hacks to support old versions of GHC that aren't feasible to maintain in haskell-ci.

What I'm trying to avoid is a situation where haskell-ci locks you in to a particular GHC source and makes it impossible to work around without rewriting your entire ci.yml file from scratch. I used to write CI configurations by hand, and I wasted hours upon hours of my life as a result. That's the entire reason I started using haskell-ci in the first place. haskell-ci's current design philosophy makes it so that it works out-of-the-box for 99% of Haskell libraries, and for the other 1%, it's simple to achieve what you want with github-patches. Locking haskell-ci into ghcup is a step away from that design philosophy, in my opinion.

[phadej]

I feel I'm not understood. So I'll wait for a concrete implementation, maybe it will make it easier for me to comment.

[RyanGlScott]

I'm somewhat afraid to dive into implementing this, as we don't appear to agree on a specification for this feature yet. As I understand it, there are two competing proposals being discussed here:

1. Introduce a single command-line switch that controls whether all jobs obtain GHC from the Ubuntu PPA or ghcup.
2. Introduce one command-line flag per GHC source, where each flag takes a version range as an argument. When generating build matrices, haskell-ci would use these version ranges to determine from where each version of GHC should be obtained.

Each option would also have a default source in the event that not enough information is provided via the command-line flags.

My personal preference is towards proposal (2), as it makes it possible to support pre-7.10 versions of GHC out of the box with haskell-ci. That being said, I do recognize that it adds a non-trivial amount of complexity to haskell-ci. Moreover, given how old some of these versions of GHC are becoming, the maintenance effort required to keep supporting them may not justify the payoff.

In light of this, I'm slowly coming around to the idea of proposal (1), as long as there is a way that I can somewhat straightforwardly patch a haskell-ci–generated file to add pre-7.10 GHCs to the build matrix. Obviously, this would not be an officially supported configuration, but I do think it would be a somewhat common case, so I think it's important to consider it. Ideally, one would be able to use the --github-patches flag to:

• Add old GHCs to the build matrix
• Change the way GHC is installed to use the Ubuntu PPA, if necessary

The first part should be straightforward. The second part is what I'm worried about. Is haskell-ci's installation step self-isolated enough to where we could replace it with another installation mechanism without too much trouble? If so, then I think I would be in support of proposal (1).

[RyanGlScott]

Here is a basic proof-of-concept github-patch for supporting both ghcup and the Ubuntu PPA in a single configuration:

diff --git a/.github/workflows/haskell-ci.yml b/.github/workflows/haskell-ci.yml
index b356f14..9457fc3 100644
--- a/.github/workflows/haskell-ci.yml
+++ b/.github/workflows/haskell-ci.yml
@@ -26,19 +26,28 @@ jobs:
     strategy:
       matrix:
         include:
-          - ghc: 8.10.3
+          - ghc: 8.10.4
             allow-failure: false
+            ghc-source: ghcup
           - ghc: 8.8.4
             allow-failure: false
+            ghc-source: ppa
       fail-fast: false
     steps:
       - name: apt
         run: |
           apt-get update
-          apt-get install -y --no-install-recommends gnupg ca-certificates dirmngr curl git software-properties-common
-          apt-add-repository -y 'ppa:hvr/ghc'
-          apt-get update
-          apt-get install -y ghc-$GHC_VERSION cabal-install-3.2
+          apt-get install -y --no-install-recommends gnupg ca-certificates dirmngr curl git software-properties-common libnuma-dev
+          if [ "${{ matrix.ghc-source }}" = "ghcup" ]; then
+            curl -sL https://downloads.haskell.org/ghcup/0.1.12/x86_64-linux-ghcup-0.1.12 > ghcup
+            chmod a+x ghcup
+            ./ghcup install ghc $GHC_VERSION
+            ./ghcup install cabal 3.2.0.0
+          else
+            apt-add-repository -y 'ppa:hvr/ghc'
+            apt-get update
+            apt-get install -y ghc-$GHC_VERSION cabal-install-3.2
+          fi
         env:
           GHC_VERSION: ${{ matrix.ghc }}
       - name: Set PATH and environment variables
@@ -47,17 +56,25 @@ jobs:
           echo "LANG=C.UTF-8" >> $GITHUB_ENV
           echo "CABAL_DIR=$HOME/.cabal" >> $GITHUB_ENV
           echo "CABAL_CONFIG=$HOME/.cabal/config" >> $GITHUB_ENV
-          HC=/opt/ghc/$GHC_VERSION/bin/ghc
-          echo "HC=$HC" >> $GITHUB_ENV
-          echo "HCPKG=/opt/ghc/$GHC_VERSION/bin/ghc-pkg" >> $GITHUB_ENV
-          echo "HADDOCK=/opt/ghc/$GHC_VERSION/bin/haddock" >> $GITHUB_ENV
-          echo "CABAL=/opt/cabal/3.2/bin/cabal -vnormal+nowrap" >> $GITHUB_ENV
+          if [ "${{ matrix.ghc-source }}" = "ghcup" ]; then
+            HC=$HOME/.ghcup/bin/ghc-$GHC_VERSION
+            echo "HC=$HC" >> $GITHUB_ENV
+            echo "HCPKG=$HOME/.ghcup/bin/ghc-pkg-$GHC_VERSION" >> $GITHUB_ENV
+            echo "HADDOCK=$HOME/.ghcup/bin/haddock-$GHC_VERSION" >> $GITHUB_ENV
+            echo "CABAL=$HOME/.ghcup/bin/cabal-3.2.0.0 -vnormal+nowrap" >> $GITHUB_ENV
+          else
+            HC=/opt/ghc/$GHC_VERSION/bin/ghc
+            echo "HC=$HC" >> $GITHUB_ENV
+            echo "HCPKG=/opt/ghc/$GHC_VERSION/bin/ghc-pkg" >> $GITHUB_ENV
+            echo "HADDOCK=/opt/ghc/$GHC_VERSION/bin/haddock" >> $GITHUB_ENV
+            echo "CABAL=/opt/cabal/3.2/bin/cabal -vnormal+nowrap" >> $GITHUB_ENV
+          fi
           HCNUMVER=$(${HC} --numeric-version|perl -ne '/^(\d+)\.(\d+)\.(\d+)(\.(\d+))?$/; print(10000 * $1 + 100 * $2 + ($3 == 0 ? $5 != 1 : $3))')
           echo "HCNUMVER=$HCNUMVER" >> $GITHUB_ENV
           echo "ARG_TESTS=--enable-tests" >> $GITHUB_ENV
           echo "ARG_BENCH=--enable-benchmarks" >> $GITHUB_ENV
           echo "HEADHACKAGE=false" >> $GITHUB_ENV
-          echo "ARG_COMPILER=--ghc --with-compiler=/opt/ghc/$GHC_VERSION/bin/ghc" >> $GITHUB_ENV
+          echo "ARG_COMPILER=--ghc --with-compiler=$HC" >> $GITHUB_ENV
           echo "GHCJSARITH=0" >> $GITHUB_ENV
         env:
           GHC_VERSION: ${{ matrix.ghc }}

Overall, the changes are not quite as invasive as I had feared, as they're mostly confined to two particular steps. In fact, I could confine the changes needed for the Set PATH and environment variables step a bit further by upstreaming the echo "ARG_COMPILER=--ghc --with-compiler=$HC" >> $GITHUB_ENV change, as that is a useful simplification that could be done independent of this.

(Note that I needed to explicitly install libnuma-dev in order to work around this bug.)

[phadej]

Resolved by #481 for now.