Add GHC, Cabal, and Stack to macOS and Windows

[hazelweakly]

Tool information

• Tool name: GHC, Cabal, Stack
• Add or update? Add
• Desired version: Latest supported GHC versions (8.10.1, 8.8.3, 8.6.5), Latest version of Cabal (3.0.0.0), Latest version of Stack (2.1.3).
• Approximate size: ~250MB per GHC. ~25MB for Cabal. ~9MB for Stack.
• If this is an add request:
  • Brief description of tool: Haskell language (already present on Linux). Stack is a cross-platform program for developing Haskell projects.
  • URL for tool's homepage: https://www.haskell.org/ https://haskellstack.org

Area for Triage: Haskell

Question, Bug, or Feature?: Feature

Virtual environments affected

• macOS 10.15
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• Windows Server 2016 R2
• Windows Server 2019

Can this tool be installed during the build?
Yes. Download and install takes approximately 2-3 minutes per GHC version.

Are you willing to submit a PR?
Yes

---

Further information:

While building cross-platform support for actions/setup-haskell, I've gone through and figured out how to install GHC, Stack and Cabal on Linux, Windows, and macOS as uniformly as possible. It would be really nice to have the most common 3 versions of GHC available on all 3 platforms so that most CI pipelines could shave off 1-3 minutes per run.

For the PR, how would you like GHC to be installed on macOS and Windows? The most reliable way to do so on windows is through chocolatey, and through macOS it's ghcup (which is how I've set it up in the action currently).

I'm happy to split the Stack tool request into a separate issue if desired.

[hazelweakly]

I'm not sure where to put this, but currently for Haskell on Linux, there's a lot more installed than seems to be necessary. Is that something you're interested in changing at all? It seems excessive to have 11 versions of GHC when common projects will only use 1 (or 3 at most).

Culturally, Haskell has a convention of supporting the last 3-4 major compiler releases, so at the time of writing that would suggest only needing GHC 8.10.1, 8.8.3, and 8.6.5. As for Cabal, having only versions 3.0.1.0 and 2.4.1.0 is sufficient (even then, Cabal 2.4.1.0 is only necessary for people who need backwards compatibility with old shell scripts).

Because the revamped actions/setup-haskell supports downloading any available GHC, it seems to me that pre-downloading less common GHC versions could safely be skipped (should you care to save time/space).

[tclem]

I'm 👍 on supporting just the last 3-4 major releases (there are way too many ghc's installed by default here).

I'm also 👍 to add Stack as part of this.

[hazelweakly]

Any update on this?

[maxim-lobanov]

@jared-w , it is on the our backlog but we don't have updates or ETA for now.

[hazelweakly]

Thanks! Would a PR help speed up the process? (I'd imagine probably not because the mac builder code doesn't seem to be in the repo?); this isn't blocking any work I have either way, but I know many projects would benefit from it.

[maxim-lobanov]

Hello @jared-w ,
Just a question about Stack. I have found that you are expecting to find Stack in tool-cache dir for all OSs: https://github.com/actions/setup-haskell/blob/master/src/installer.ts#L69
We will put it there for Windows / macOS. But it looks like currently, for Ubuntu we install Stack to different directory. Does it mean that your action downloads it every build?

[hazelweakly]

@maxim-lobanov there's actually a subtle reason for why I did things that way although it ultimately boiled down to a trade-off between code complexity and speed. tl;dr yes it installs stack every time on linux, but it doesn't have to.

On Linux, stack is preinstalled, but not to a versioned directory. As such, the only reliable way of making sure the right version of stack is on the path is checking for the version of stack using something like stack --version-numeric and parsing that to determine if the version specified is already installed. Otherwise the setup action would check if stack existed at the default install path (yes) and then would be done; which means that if you manually specified a different version, it wouldn't actually download it. The lack of a versioned path also makes it difficult to use setup-haskell with multiple versions of stack.

I could've special cased the behavior for stack but it was a wall clock time difference of less than 5 seconds between installing stack and not and I was reluctant to add a complex bit of logic to a rarely used codepath.

With tool-cache, i can version the downloads which avoids the issue. Cabal and ghc both were accessible on all operating systems either through a tool that supported versions (ghcup, chocolatey), or a versioned path (ubuntu), which also avoided the issue.

[maxim-lobanov]

@jared-w , that sounds good to me.
On Windows and macOS we will install Stack to the tool-cache dir.
If you want us to consider moving stack to tool-cache dir on Ubuntu, feel free to raise separate issue.

[phadej]

https://hub.zhox.com/posts/introducing-haskell-dev/ contains relevant information.

With #919 it seems that even cabal-install and ghc are now preinstalled, msys2 isn't (at least it's not mentioned in included software). Without msys2 the cabal-install and ghc are not so useful (I think you could not compile network package for example).

[maxim-lobanov]

@phadej , Actually, MSYS2 was added to our images recently too in scope of #30. It should be deployed soon

[phadej]

The failing jobs in #919 both do seem to install msys2. Is it installed with chocolatey or by some other means? Having multiple installations would be a recipe for disaster.

To answer myself: Looks like it's isntalled manually https://github.com/actions/virtual-environments/blob/master/images/win/scripts/Installers/Install-Msys2.ps1 so chocolatey itself won't detect that it's installed. Have to check whether cabal is installed after msys2 and whether cabal scripts have detected msys2. Not today though.

[phadej]

Also I should ask, how your image deployment works. May I assume that once a job in a repository (cabal in this case) gets a new version of an image all other new jobs will get the new image version as well. Or is it arbitrary? In short, can I already change cabal CI scripts to assume that msys2 is installed? As it seems that (some) jobs run using newer image version.

…

On 21. May 2020, at 18.08, Maxim Lobanov ***@***.***> wrote:  @phadej , Actually, MSYS2 was added to our images recently too in scope of #30. It should be deployed soon — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[maxim-lobanov]

@phadej , yep, we don't put MSYS2 on PATH for now because it will override some default tools and break existing customers so we just install it to the separate directory.

We deploy images by rings (the whole ring at a time) and your repository is attached to one particular ring. It means that if your job got new image version, all next jobs will consume new image version too.

[phadej]

@maxim-lobanov that clarifies and sounds good. Thanks for the explanations!

[phadej]

I relaying a message from haskell/cabal#6829 (comment)

---

What I don't get is why the image has to have every single version installed at once? Why can't you simply use something like AppVeyor's build matrix? Isn't that simpler? or does github actions not support something like that.

The motivation seems to be that having tools preinstalled would save startup time.

The thing that takes largest amount of time is msys2, which you say will be preinstalled or could be. installing GHC and cabal on appveyor takes 1minute. it's just a download and extract. It'll save bandwidth sure, but highly doubt much in compile time..

You can speed this up by instead of caching the installs, cache the binaries using --cachelocation and --use-download-cache which should drop the time needed down to seconds (just unzip) and make your life a lot easier...

[dibir-magomedsaygitov]

We have added GHC, Cabal, and Stack to macOS and Windows images. Changes were merged and will be delivered to all VMs in a week.

[dibir-magomedsaygitov]

All changes are delivered to VMs. Feel free to open the thread if you have any concerns.