Skip to content
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

Open
hasufell opened this issue Sep 1, 2020 · 1 comment
Open

Allow installing HEAD GHC? #6

hasufell opened this issue Sep 1, 2020 · 1 comment

Comments

@hasufell
Copy link

hasufell commented Sep 1, 2020

At least from ghcup side, it isn't hard to support. It can already be done manually:

ghcup -n install ghc -u '{"dlHash": "", "dlSubdir": { "RegexDir": "ghc-.*"}, "dlUri": "https://gitlab.haskell.org/api/v4/projects/1/jobs/artifacts/master/raw/ghc-x86_64-fedora27-linux.tar.xz?job=validate-x86_64-linux-fedora27" }' head

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

@hazelweakly
Copy link
Collaborator

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 ghcup install ghc HEAD would already be working without further changes.

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 https://downloads.haskell.org/~ghc/8.10.2/ghc-8.10.2-x86_64-unknown-mingw32.tar.xz), and Chocolatey itself seems to require checksums, which I'm not sure can be gotten easily from gitlab for validation builds.

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 ghcup install ghc HEAD worked. It's better than nothing, and I'd be loath to let idealism get in the way of progress, especially when it comes to CI tooling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants