The action installs the wrong version of cabal of MacOS

[newhoggy]

See https://github.com/input-output-hk/cardano-db-sync/pull/441/checks?check_run_id=1586145305

Note, on Linux, the correct version gets installed:

[hazelweakly]

Sorry for not replying earlier. Thanks for pointing this out! So, there's an interesting chain of events happening here.

• Cabal is installed by default with ghcup, leading to an existing ~/.ghcup/bin/cabal binary.
• This binary exists, so ghcup set cabal $version is invoked. But... the version is not one that is downloaded. So we need to run ghcup install cabal $version first (and then set).

The problem is we really don't want to stick a bunch of install logic in the function that checks whether or not something is installed. I encountered this before when ghcup didn't have a way to check which versions of cabal were installed in a file path manner. Now it does, so that leads to the natural solution of

async function isInstalled(
     const installedPath = await fs
-      .access(`${ghcupPath}/cabal`)
+      .access(`${ghcupPath}/cabal-${version}`)
       .then(() => ghcupPath)
       .catch(() => undefined);

So that solves "systems that rely on ghcup to install cabal and then try to install a new different of cabal later won't have that version correctly setup" (for real, this time).

The second issue is that ghcup install cabal 3.4.0.0-rc4 fails. I don't think this is one that I can fix. The cabal-install prereleases that ghcup gets are obtained from Oleg's personal server and really can't handle the kind of traffic that a CI pipeline produces. The better solution is to try and figure out how to get prereleases of cabal-install and GHC available in a more consistent manner.

As it stands, pre-releases of GHC and Cabal look like this:

tool	installer	OS	location	version
GHC	ghcup	macOS/linux	ghc's gitlab	9.0.0.20200925 (published 2020-09-28)
GHC	chocolatey	windows	ghc's gitlab	(ghc --pre or 9.0.1-alpha1) 9.0.0.20200925 (published 2020-09-28)
GHC	ppa	linux	hvr's uploads	(ghc-head) ghc-head-8.7.20181217+git.1.f99d898-9~18.04 (published 2018-12-17)
cabal	ghcup	macOS/linux	Oleg's personal server	3.4.0.0-rc4 (published 2020-10-13)
cabal	ppa	linux	hvr's uploads	(cabal-install-3.4) cabal-install-3.4+git20201028.2.7907a67-6~20.04 (published 2020-10-29)
cabal	ppa	linux	hvr's uploads	(cabal-install-head) cabal-install-3.3+git20200529.2.36ab7a0-6~14.04 (published 2020-05-29)
cabal	chocolatey	windows	mistuke.blob.core.windows.net	(cabal --pre or 3.4.0.0-rc3) (published 2020-10-10)

There is absolutely no way to make this consistent,currently. Any pre-release logic is going to have to happen entirely on the end-user's side of things, and I don't feel comfortable setting up CI with insecure flags and hammering a personal server to test that something not designed to be used in CI can indeed be hacked into a CI pipeline.

[newhoggy]

Please see:

"I switched all urls to http. Your workaround can be removed." - Julian Ospald

https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/102

[hazelweakly]

That'll work for now; I'm happy to remove the testing of 3.4.0.0-rc4 if it's needed in the future (eg @phadej requests that)

[phadej]

@jared-w I would prefer that GitHub doesn't "ddos" my (to some approximation) server. Testing release candidates is however welcome.

Clarification: I don't have access to haskell.org servers to upload release (candidate)s there. (And I like this lack of power + responsibility).

[hazelweakly]

@phadej that's very reasonable and understandable. Thanks for the update!

I'm going to close this as the related PR was merged. And I'll address the windows one today as well. Feel free to open a new issue if things stop working :)

[hasufell]

@phadej could we upload cabal pre-releases into webhost.haskell.org:~/ghcup/cabal instead then? That still conveys they aren't official releases, right?