-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow installing HEAD GHC? #6
Comments
I'd certainly be a fan of supporting installing HEAD GHC. Currently, the setup-haskell action will technically fall through on any arbitrary string, so That said, I wouldn't want to "officially" support a GHC from head unless I could somehow get a 1-to-1 relationship between a given HEAD git commit and a build on windows, linux, and macos. For linux and macos this is mostly already taken care of since they both use the same tool and (barring inescapable race conditions), should always resolve to the same HEAD. Windows is trickier, though. Chocolatey seems to work by having a script for every version under the hood, which resolves to a hardcoded url (eg Then there's the elephant in the room. Given the natural instability of HEAD GHC, what would be the best course of action when one GHC has built correctly, but not all of them have? This is something rust struggles with for its nightlies. They finally solved it with this solution of updating to the latest "viable" nightly. However, I'm not sure if that strategy would work for Haskell. Despite recent work, windows remains very much a second class citizen, even amongst CI tooling. If someone wants to run a linux only CI, should their HEAD GHC be held back because windows hasn't built correctly as recently as linux has? If someone runs a CI pipeline for linux on HEAD GHC, and then adds windows, should their linux build start breaking because the action invisibly downgraded to an older version of HEAD? Should a way of "pinning" the nightly be proposed, it'd have to be translatable across ghcup and whatever would work on Windows; I'm not even sure what method of pinning makes the most sense, there's dates and git revs, but they're not the only ways to specify more exact versions. These are questions I don't have immediate answers to, and I certainly don't have answers on how to somehow coordinate "HEAD" between ghcup and some windows-specific installer, much less coordinating a "minimum viable HEAD" should that ever be a thing. In the short term, though, I'd be happy to make sure that something like |
At least from ghcup side, it isn't hard to support. It can already be done manually:
This doesn't do platform detection etc, but it wouldn't be hard to support something like
ghcup install ghc HEAD
.I'm not sure about chocolatey, but the GHC CI job also builds windows artifacts: https://gitlab.haskell.org/ghc/ghc/pipelines/24056
The text was updated successfully, but these errors were encountered: