GHC Nightlies: How would you use them?

Haskell Foundation
#1

The GHC project and GHCup are now closer than they were in the past to being able to produce conveniently-installable nightlies of GHC. As this comes closer to being a reality, I’d like to reach out a bit to the community to find out what uses of nightlies will bring the most value so that we can make sure that the final design supports as many peoples’ and companies’ needs as possible.

First, a few things that aren’t on the table for the very first iteration of this practice:

  • Nightly releases of tools that aren’t part of a standard GHC bindist, like HLS, will not be included
  • Initially, nightly builds will lack profiling libraries and a few other useful things
  • Other important tools, like stack and cabal, may or may not support the nightly releases
  • Nightlies are not initially guaranteed for all architectures and OSes every night

Some of these things may be able to happen in the not-so-far future, but it seems better to build on what’s already available rather than block until everything is perfect.

Here are a few different use cases that I can imagine for nightly builds:

  1. Convenient setup of CI that tests against the nightly and head.hackage
  2. Companies can test specific nightlies to help the GHC team assess the impact of compiler changes on large code bases that are not open-source, but are nonetheless important
  3. Users who are eagerly awaiting new features can easily test them and provide feedback before they appear in a release
  4. Maintainers of libraries can more easily follow GHC development, hopefully reducing the lag time between a compiler release and widespread adoption

My question for you is the following: how could you use nightlies of GHC to improve your Haskell experience?

I say “you” because I think that answers grounded in someone’s real experience are a more useful source of requirements than answers based on a theoretical other person, so please answer based on yourself, your company, your open-source project, or your research group. And I’m specifically asking about use cases here because I want to avoid intermingling a design discussion with requirements gathering. That step will come.

Based on your feedback, I’ll put together a summary and overview for the various tool developers who will need to coordinate for nightly builds to become more convenient to use.

Thank you for your input! If you’d like to share it confidentially, please feel free to email me at david@haskell.foundation.

13 Likes
Haskell Foundation December and January 2022-2023 Update
#2

Nightly build only for the master branch, or the release branches? I assume the original message is only about master, since there only seems to be scheduled jobs for master for the time being.

2 Likes
#3

I’m enthusiastic about (3) and (4). Reducing the lag time between a compiler release and widespread adoption sounds like a great thing to me.

1 Like
#4

My understanding is that master is what’s easy to accomplish today, but I’m happy to follow up and clarify. Would nightlies from release branches enable any valuable use cases for you?

1 Like
#5

Yes, and I believe it can be more useful to average Haskell developers compared to master. I think of the release branch as a rolling release that’s feasible to use in production, and it closes the time gap between bugfixes cherry-picked to the branch and an actual point release gets announced. Additionally, there’s much less risk of breaking HLS, since once a release branch is supported by HLS, it often stays that way for future updates to the branch.

2 Likes
#6

As a hobbyist, I think having nightly releases of the master branch would make it much easier for me to quickly identify and help fix broken packages, especially if combined with GHC.X.Hackage which would accept patches from non-maintainers. it seems the existing head.hackage is enough as David explains in his reply below.

3 Likes
#7

I would absolutely use this in my libraries in CI to help speed up adoption to newer GHCs and to provide feedback on things before they are properly launched. If I had this available when Simplified Subsumption was a thing, then I’d have whined a lot earlier, and maybe could have saved a bunch of work :sweat_smile:

2 Likes
#8

FYI, it’s already possible to reuse GHC GitLab artifacts to install ghc-head or other major releases using ghcup:

ghcup install ghc 9.7 -u "https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-linux-fedora33-release.tar.xz?job=x86_64-linux-fedora33-release"
ghcup install ghc 9.6 -u "https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/ghc-9.6/raw/ghc-x86_64-linux-fedora33-release.tar.xz?job=x86_64-linux-fedora33-release"

It likely takes more work to achieve what David has in mind, but this might be an interesting starting point for folks that want to test stuff.

2 Likes
#9

As a library and applications author, I think my main blocker would be to have my dependencies using these nightly releases, unless the breakage of the surface APIs (base & compiler behaviours) becomes radically more contained.

That being said it would be confined to a CI job because there is no way I’m programming on a Haskell codebase without HLS nowadays or ghcid nowadays.

4 Likes
#10

Thanks for this, I’d been seeing nightlies as being mostly a mechanism for increasing alignment between GHC master development and users, mainly as a mechanism for getting feedback more efficiently. I’ll include faster access to bug fixes on a release branch as a use case that would be nice to support when I write the report.

Today, the GHC team maintains a Hackage overlay that includes patches to large portions of Hackage that make it compatible with GHC master. This overlay is called head.hackage. The GHC.X.Hackage proposal was about snapshotting head.hackage for a given GHC release as a stopgap while the ecosystem catches up - if you’re working with master-based nightlies, then the already-existing head.hackage should serve your needs. Or is there something that I’m misunderstanding?

That’s a lot of the background work that’s already gone on - this initiative is to make it easy to test with snapshots, and to see what we can do to enable other use cases that aren’t well-supported by the existing tooling. The commands you’re pointing out are useful, but there’s enough difficulty in using them that non-experts will have trouble (e.g. what if they’re not on Fedora 33?).

This is a good point. Does head.hackage address this concern, or is something else needed?

Absolutely. From what I can see from a quick scan of the source code of ghcid, I suspect that it could be made to work pretty easily with nightlies. It fires up ghci as a subprocess, rather than hooking into the guts of GHC, and it has a pretty small dependency footprint.

1 Like
#11

The only use case I would see is to build a project that depends on a nightly compiler and only builds with a nightly (this will ultimately happen, just like it does in rust).

That would mean to retain all nightlies indefinitely.

1 Like
#12

I have indeed overlooked the possibility of using head.hackage directly and misunderstood/misremembered what GHC.X.Hackage is about. Also together with @TerrorJack’s suggestion of using ghcup to install CI artifacts directly, it seems it is already possible to something like what I had in mind.

That said, there is still much room for improvement in my opinion:

  1. It would be nice if I could “activate” head.hackage by adding a single remote import to a cabal.project file. I believe that could both set up the repository and enable the custom constraints for the patches.
  2. it would be nice if ghcup had a command to build the latest head artifact which automatically chooses the right distribution. Of course that probably needs to be coordinated from the GHC side too.
  3. Ideally, there would be one command I could run to switch to a GHC nightly and head.hackage with patches at the same time. This command would also update the nightly if it is outdated.

I want to place emphasis on switching because inevitably there will be times where I will want to get stuff done without the hassle, so then I need to be able to switch quickly to a proper release.

2 Likes
#13

I would like to urge everyone to not see this as a magical feat, but view it for what it is: a symptom of a much more grave problem. Namely GHC master is incompatible with large portions of Hackage.

head.hackage should not (have to) exist!

6 Likes
#14

Thank you for this point - it sounds like making it easy to switch a local development workflow between versions enables important use cases.

1 Like
#15

Nightly support for library CI would be good.
A large chunck of effort migrating GHC versions is getting all libraries to build with the new GHC release.
It’s unfortunatly still often the case that supercede is the only user of a library, so we have to maintain it :pensive:

I don’t think we’d have the resources to test our code against nightly builds currently since we’re deeply integrated within nix and have roughly 100 dependencies for the main supercede-web project. All of these have to support the new ghc version, and their dependency depencencies also need to support the new ghc version, etc.

1 Like
#16

See ghcup compile ghc.

GHCup is unlikely to add functionality to manage your cabal configuration. It seems this would be a job for a bash function/alias.

What do you mean with “outdated” nightly? Do you want a shorthand version of “install the latest nightly”?

2 Likes
#17

While this would be a great step, it doesn’t particularly solve any use cases for our company. We’re not on the bleeding edge, but we do upgrade our GHC once every year or two to get new features. At that point, we switch to the latest version with wide library support - e.g., we recently switched to 9.2. Each time we migrate, we have quite a few changes to make to our code. That’s fine, but it’s an expense we want to take on only periodically.

The nightlies are too far ahead of what we use in our mainline code base to be of much help. We can’t try them out without also making significant changes to our code base, which is a cost we’d rather pay when we do an upgrade, rather than continuously try to maintain two versions of our code.

It took a long time for the 9.x series to get wide library support on Stackage. If the effect of the easy availability of the nightlies is to speed up library updates by library authors, then it will indirectly be a win for us.

6 Likes
#18

For me the most important aspect of reducing the latency with which produced artifacts are made available to downstream consumers is tightening the feedback loop, and I mean “feedback” in the control theory/systems engineering/process engineering sense. Changes to upstream have knock-on consequences for downstream, and the sooner those consequences can be observed and upstream informed about them, the more easily upstream is able to course-correct or amplify as necessary.

The most practical example in the case of GHC Nightlies would probably be integrating them into CI systems, as many commenters here have pointed out.

1 Like
#19

I echo @parsonsmatt’s response: I would gladly put nightly into CI on all my libraries. Of course, it’ll fail if I use any third party deps, but hopefully a critical mass of the ecosystem will join in and allow everyone to test their code against upcoming releases of GHC.

My ideal state would be that this nightly job would be green, but if it ever fails, that’s a signal to me that I could fix something to “get ahead” of the next release (or make an issue upstream if there’d be an issue). It’d be purely an informational signal; contributions would not be blocked on it, and I would not need the nightly binaries to be long-lived

3 Likes
#20

Thank you all for your input about use cases here - I’m taking them onward in the process. I’ll go do some consensus-building work and then report back.

2 Likes