search

haskell-CI / setup

[WIP] Set up your GitHub Actions workflow with a specific version of Haskell (GHC and Cabal)
MIT License
1 stars 2 forks source link

Fix macos ghcup and cabal flags #4

Closed hazelweakly closed 4 years ago

hazelweakly commented 4 years ago

This fixes a few issues:

  1. There's a curious bug where if multiple versions of ghc are preinstalled with ghcup and one of them is set as a default, the path could become subtly wrong even though the outputs of the action were correct.
  2. Running cabal update when stack is enabled costs time for people who enable stack but want to use the system ghc to shorten their CI runtimes.
  3. The default way this action was setting http-transport is actually not backwards compatible to all supported versions of cabal. I couldn't find any mention of this in the documentation, but I've adjusted the behavior accordingly.

Hopefully the minor adjustments to the tests should catch some of these regressions should they occur again.

hasufell commented 4 years ago

There's a curious bug where if multiple versions of ghc are preinstalled with ghcup and one of them is set as a default, the path could become subtly wrong even though the outputs of the action were correct.

Is this anything ghcup specific or about the code of this github action?

hazelweakly commented 4 years ago

Is this anything ghcup specific or about the code of this github action?

There's nothing super ghcup specific about this. It's more an artifact of how things combine together and how I had implemented the short-circuiting behavior. Essentially, ~/.ghcup/bin is where cabal is stored so that's added to the path. ~/.ghcup/ghc/ver/bin is where ghc is installed, but ghcup set ver will symlink it into ~/.ghcup/bin as well.

All fine and good, but now if I:

  1. Run ghcup install ver1 && ghcup install ver2
  2. Run ghcup set ver1, and add ~/.ghcup/ghc/ver1/bin to the path and ~/.ghcup/bin to the path
  3. Later run the action with ver2 specified

The short-circuit code path only checks that ~/.ghcup/ghc/ver2/bin is available and adds that to the path, without ever running ghcup set ver2 to change ~/.ghcup/bin/ghc correctly. (this is the bug)

The error shows up consistently because, in the action, ghc is installed first and then cabal, so the ~/.ghcup/bin path always appears first, resulting in the behavior noted in this issue where the right ghc is installed, and works if referenced by absolute path, but the ghc that shows up on the path is the pre-installed one.

Lastly, I suspect that the reason this shows up without having run setup-haskell twice is because (presumably) during the configuration to add ghc by default to macos, ghcup set 8.10 was ran, turning a weird niche corner-case bug into a very common one :)