Add cabal 3.4 to the list of versions

[neilmayhew]

This will make latest equal to 3.4.0.0 instead of 3.2.0.0 which will avoid unnecessary downloading since the build runner has 3.4 installed.

---

This change is 

[neilmayhew]

Fixes #45

[phadej]

Where from the 3.4.0.0 versions are fetched from? If these are prerelease fetched from my oleg.fi please remove them. My server is not behind any kind of CDN or anything like that.

cabal-install-3.4.0.0 is not officially released, yet (2020-11-19).

[neilmayhew]

Cabal 3.4.0.0 is already installed on the Linux build runners that GitHub is using. This change stops the action from using 3.2.0.0 which then has to be downloaded.

It's not completely clear to me how the action will end up downloading Cabal. It tries apt-get first and then ghcup. I think it's likely that the build runners are configured to use hvr's PPA.

[phadej]

Firstly, I MUST nitpick. There is Cabal library, and there is cabal-install the tool. See https://gist.github.com/merijn/8152d561fb8b011f9313c48d876ceb07

Please use cabal-install in your listings here (and virtual-environments).

Secondly, the cabal-install-3.4.0.0 is not available on Windows platforms. (You need to opt in to use pre-release software in choco).

The cabal-install-3.2 and cabal-install-3.4 on Ubuntu can co-exist, so the right solution now is to have cabal-install-3.2 re-instantiated into Ubuntu images.

[hazelweakly]

This is not something we want to do for many reasons.

Firstly, cabal-install 3.4 is a pre-release version.

Secondly, windows and macos do not have cabal v3.4 available.

Well, they technically "do", but you have to download them specially, choco install cabal -m --version 3.4.0.0-rc3, and ghcup install cabal 3.4.0.0-rc4 respectively. Both chocolatey and ghcup mark cabal-install 3.4.0.0 as clearly being a prerelease version. And, in fact, they have different versions of it, so who knows what's actually different between them and the version on Herbert's ppa. On top of that, ghcup's link to cabal 3.4 points to Oleg's oleg.fi server which is not something that can or should be exposed to the entirety of setup-haskell by default (or at all, quite frankly; I'm surprised it's in ghcup at all)

Lastly, the reason the linux runners (and only the linux runners) have cabal-install 3.4.0.0 is due to the sole reason that apt-cache search cabal-install-[0-9] returns

cabal-install-2.4 - Command-line interface for Cabal and Hackage
cabal-install-3.0 - Command-line interface for Cabal and Hackage
cabal-install-3.2 - Command-line interface for Cabal and Hackage
cabal-install-3.4 - Command-line interface for Cabal and Hackage

and only the latest version is installed. That is, there's nothing in the ppa that marks 3.4 as a prerelease. I'm not sure if ppa's actually have this functionality or not, but I suspect they don't. Just running apt install cabal-install will install the one provided by ubuntu, which is 2.4.0.0 and also installs ghc 8.6.5, so that's not a way to get the "latest release" of cabal-install.

The cabal-install-3.2 and cabal-install-3.4 on Ubuntu can co-exist, so the right solution now is to have cabal-install-3.2 re-instantiated into Ubuntu images.

This, I agree with. Unfortunately, the scripts for the github environments are designed in a way that they don't require manual updating to get the "latest version" of things. This is good because it means there's no maintenance burden to get new releases of software, but as long as pre-releases of cabal-install are indistinguishable from full releases on linux, that will be tricky. Unless they just installed the last 2 versions of cabal? Seems like a really unfortunate workaround, though. Alternatively, cabal-install could be installed through ghcup on linux as well as macos.

---

As an unrelated note, the Cabal vs cabal-install distinction is probably a completely lost cause at this point. Both ghcup and chocolatey both use cabal as the name to install cabal-install, and everyone colloquially refers to cabal-install as cabal. I think the distinction is worth keeping in mind when possible, but it rarely seems to matter for most in practice.

[hazelweakly]

It's not completely clear to me how the action will end up downloading Cabal. It tries apt-get first and then ghcup. I think it's likely that the build runners are configured to use hvr's PPA.

This is correct. The build runners use hvr's PPA and the action tries to do things in the most "canonical" order per platform (or, ultimately, that which will result in the least downloads and least surprise). Consequently, on linux, the order is check known paths/$PATH -> ppa -> ghcup -> give up

[phadej]

This, I agree with. Unfortunately, the scripts for the github environments are designed in a way that they don't require manual updating to get the "latest version" of things. This is good because it means there's no maintenance burden to get new releases of software, but as long as pre-releases of cabal-install are indistinguishable from full releases on linux, that will be tricky.

If it so, then I'll ask @hvr to not populate his PPA with neither pre-releases of cabal-install nor GHC.

[phadej]

That is, there's nothing in the ppa that marks 3.4 as a prerelease.

There kind of is

% sudo update-alternatives --config opt-cabal                         
There are 7 choices for the alternative opt-cabal (providing /opt/cabal/bin/cabal).

  Selection    Path                       Priority   Status
------------------------------------------------------------
  0            /opt/cabal/bin/cabal-3.4    30400     auto mode
  1            /opt/cabal/bin/cabal-2.0    20000     manual mode
  2            /opt/cabal/bin/cabal-2.2    20200     manual mode
  3            /opt/cabal/bin/cabal-2.4    20401     manual mode
  4            /opt/cabal/bin/cabal-3.0    30001     manual mode
  5            /opt/cabal/bin/cabal-3.2    30200     manual mode
* 6            /opt/cabal/bin/cabal-3.4    30400     manual mode
  7            /opt/cabal/bin/cabal-head   30300     manual mode

I asked @hvr (sometime ago) to mark alphas/release candidates/head as low priority, so if you'd install cabal-install-3.2 and cabal-install-3.4 now (when 3.4 is release candidate) the 3.2 would have higher priority and be the one linked to /opt/cabal/bin/cabal. But I'm afraid that information is not available before you install the packages.

[neilmayhew]

It sounds like the changes in this PR should be dropped for now, and I'm happy to close the PR, but it has given rise to a bigger discussion. Would it be helpful if someone was to open an issue in actions/virtual-environments?

[hazelweakly]

It would be helpful, for sure, but I'm personally reluctant to do so without an actual solution in hand. Keeping Haskell tooling up to date in github actions is pretty critically reliant on the scripts being maintenance free, so encoding some specific knowledge about "version 3.4 isn't ready yet" is not really possible. (I'm sure with enough pestering, an exception could be made, but I'd rather not be that person).

The easiest and cleanest solution that I can see is that @hvr pulls the pre-releases from the PPA (or somehow names it something like cabal-install-pre-3.4 which would make it possible to exclude it programatically). As the VMs are updated weekly, even if the virtual environment team doesn't do anything, the solution is eventually resolved without much fuss; something I very much like.

Then the issue we would open would be along the lines of "please regenerate the linux images little sooner than normal" vs "please change some code, regenerate the images, and then be prepared to do this again in a few months".

[neilmayhew]

It would be great if hvr could have two PPAs, hvr/ghc and hvr/ghc-unstable or hvr/ghc-prerelease.

[neilmayhew]

I'll ask @hvr to not populate his PPA with neither pre-releases of cabal-install nor GHC.

@phadej Has there been any progress on this? This PR has stalled.

We could leave this PR open until 3.4 is released, but I don't know how long that is likely to be. The only cost in the meantime is some extra downloading on each build.

[neilmayhew]

I guess another solution would be to change the virtual environment to install the four latest versions of cabal-install, as is done for ghc. That would provide the desired version of cabal-install for a significant proportion of builds, I expect. (3.4, 3.2, 3.0, 2.4)