Consider distributing nightlies

[hasufell]

GHC will support nightlies via ghcup soon:

• Implement support for nightlies ghcup-hs#824
• https://gitlab.haskell.org/ghc/ghcup-metadata/-/issues/1

The way this works is that GHC CI just builds and then creates and updates a metadata automatically: https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/rel_eng/mk-ghcup-metadata/mk_ghcup_metadata.py

HLS could do something similar. We'll have to figure out a storage solution, e.g. S3 (we already use a private bucket for cabal cache).

---

@wz1000 @fendor @michaelpj @david-christiansen

[hasufell]

1 month of storage would be roughly 100GB I think. If we utilize downloads.haskell.org and only retain one month, then we might have an easier solution that doesn't require rate limiting or monitoring costs.

[michaelpj]

I am mildly -1 on this.

I think the benefit here is some additional convenience for users who want to use a bleeding-edge version. But I think it's reasonable to consider this a power user use case, and relatively uncommon. And the amount of convenience is not that high: users can already compile it themselves easily enough (does ghcup support compiling from HEAD?).

The calculus is better for our released versions. There we are providing convenience for lots of users, including especially inexperienced users for whom it's a big deal.

I don't know how high the cost is, but it's One More Thing.

[hasufell]

I'm not sure what your concern here is. If someone wants to do the work, what speaks against it?

This isn't really something with high commit value. If it doesn't work or causes issues, it can simply be discontinued.

[fendor]

If this requires basically zero maintenance and can be easily turned off on a whim, I am fine with nightlies.
Just uploading the binaries somewhere, which is the only thing that we might need to discuss since storage may cost money, will not affect the overall maintenance burden of HLS.

I think we benefit from quicker feedback loops, since it helps end-users to quickly checkout new features and report issues before a release.

[hasufell]

If this requires basically zero maintenance

Nothing requires zero maintenance. Postulating that as a requirement is a sure way to lose contributions.

[hasufell]

I think we benefit from quicker feedback loops, since it helps end-users to quickly checkout new features and report issues before a release.

Yes and haskell/ghcup-hs#840 is another proof showing that there is a class of users who are not willing or interested to compile any toolchain part from source.

In that sense, "build from master" will not suffice for them.

[fendor]

Postulating that as a requirement is a sure way to lose contributions.

What I meant was, it doesn't require a lot of regular maintenance. I didn't mean to say no maintenance, apologies!

[hasufell]

Postulating that as a requirement is a sure way to lose contributions.

What I meant was, it doesn't require a lot of regular maintenance. I didn't mean to say no maintenance, apologies!

Yes, it's less troublesome than an undermaintained plugin.

And it doesn't block other parts of CI.