Closed hazelweakly closed 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?
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:
ghcup install ver1 && ghcup install ver2
ghcup set ver1
, and add ~/.ghcup/ghc/ver1/bin
to the path and ~/.ghcup/bin
to the pathver2
specifiedThe 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 :)
This fixes a few issues:
Hopefully the minor adjustments to the tests should catch some of these regressions should they occur again.