Action doesn't handle pre-installed GHCup properly

[maxim-lobanov]

This action works perfectly if you don't have pre-installed ghcup on machine. It uses apt to install versions and they are resolved correctly. But when we install GHCup on machine (to the default location $HOME/.ghcup) we can see very strange behavior:

• Action tries to find pre-installed version of GHC in ${process.env.HOME}/.ghcup.
• When version is found in $HOME/.ghcup, action tries to invoke ghcup set command and download own version of ghcup to toolcache folder: https://github.com/haskell/actions/blob/main/setup/src/installer.ts#L210

So even if ghcup is pre-installed on machine and available in PATH, action will download own ghcup to tool-cache and use it for all operations. Probably, ghcupBin function should try to find ghcup in PATH and download in case if it is not found.

[hazelweakly]

Thanks for the report! I've attempted to make this action work perfectly with a pre-installed ghcup, but I should probably figure out how to test that in CI properly to ensure it works.

• Checking $HOME/.ghcup is intended behavior. I don't know of a more reliable way to determine where GHCUP has stored its downloaded binaries. Although, thinking through it, I suppose checking for the existence of GHCUP_USE_XDG_DIRS and adjusting accordingly would be the best way?
• ghcupBin should indeed find the ghcup in the path and use that instead. I naively programmed it to use the toolcache as I assumed that any preinstalled software on the runners would use it as well. This was wrong, so I'll fix that.

When trying to investigate this earlier, I found it necessary to unconditionally upgrade ghcup to make sure that it was the latest version so that it would always have access to the most recent list of GHC versions. Something like this:

const pathBin = await which('ghcup', false);
if (pathBin) {
  await exec(pathBin, ['upgrade']);
  return pathBin;
}
// download + install otherwise

Would this work?

[maxim-lobanov]

Agree with the points above but I am not sure that we should upgrade ghcup. As I know, ghcup works correctly when it is outdated but throws warnings that can be easily ignored. Personally, I don't like to upgrade ghcup for two reasons:

• Additional build time
• Self-hosted agents (I am strongly sure that action shouldn't modify (update / re-install) tools on my own agent)

[hasufell]

I don't know of a more reliable way to determine where GHCUP has stored its downloaded binaries

There's a ghcup whereis command now. If cabal-install is installed ghcup whereis --directory cabal will return the binary dir. Arguably, maybe there should be a ghcup whereis binary-dir.

I found it necessary to unconditionally upgrade ghcup to make sure that it was the latest version so that it would always have access to the most recent list of GHC versions.

That's correct. Older ghcups may not receive all new GHC updates. That can happen when the bindist format changes, for example.