search

haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.62k stars 353 forks source link

Consider distributing nightlies #3652

Open hasufell opened 1 year ago

hasufell commented 1 year ago

GHC will support nightlies via ghcup soon:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

If this requires basically zero maintenance

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

hasufell commented 1 year ago

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 https://github.com/haskell/ghcup-hs/issues/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 commented 1 year ago

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 commented 1 year ago

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.