Distribute binaries via Homebrew

[ad-si]

It would be cool if I could install hls it with a simple:

brew install haskell-language-server haskell-language-server-wrapper

Here is the documentation on how to add it to Homebrew:
https://docs.brew.sh/Adding-Software-to-Homebrew

[jneira]

More installation methods supposes to reach more users and that is good. However they should be set up and more importantly, updated. Ideally it should be done in ci automatically.
So we need someone willing to accomplish the task 😄

[jneira]

Some investigation has been done by @ELLIOTTCABLE: Homebrew/discussions#386
Thanks for it!

[jneira]

haskell-language-server is on hackage now and can be installed in a more friendly way with cabal install: https://hackage.haskell.org/package/haskell-language-server

[kret]

haskell-language-server is now available as a Homebrew formula (brew install haskell-language-server). This is a version compiled with current GHC from Homebrew (8.10.4). I hope it works 😅

I guess this is not ideal (single GHC version support), but I think it is a reasonable compromise between Haskellers' needs and Homebrew's rules.

IMO it would be great to distribute the whole release. As I see it we could create a "Haskell tap" similar to this: https://github.com/kret/homebrew-tools, but in an official Haskell repo. There we could distribute binaries without need to strictly conform to Homebrew rules, but at the cost of having to occasionally update it ourselves.
I was thinking about distributing the wrapper and language server binaries per GHC version so that users could pick whatever they need, perhaps also with a single command full release installation. I can prepare such version on my private tap as an example and then it could be moved over to official repo, if accepted as a solution.

[kret]

Updated my private tap (https://github.com/kret/homebrew-tools).
It now contains 5 casks:

• kret/tools/haskell-language-server-full
• kret/tools/haskell-language-server-wrapper
• kret/tools/haskell-language-server-8104
• kret/tools/haskell-language-server-884
• kret/tools/haskell-language-server-865

The full contains the full release of course, the rest contains single binaries (8104 - because dots are not allowed in names, hyphens could be there if you think they look better).

You can play around with un/installing and using to verify if that is usable.
All comments are welcome, I can make updates, or you can open PRs of course.

If this becomes satisfactory, we can decide next steps, like:

• moving to an official Haskell/HLS tap,
• which binaries to include like this,
• automating tap refresh upon new release,
• ?

[jneira]

@kret wow, that is really really great, many thanks for setup the formula and the alternative packages

I think the next immediate step could be add homebrew as a new install method in the README and make it public (in the next release announce f.e.)

moving to an official Haskell/HLS tap,

Create a new repo in the org is not a trivial task, maybe we could start to use your repo (or a different under another org, as you consider).

automating tap refresh upon new release,

that would be nice, what would be the update suppose? changing .rb files?

[jneira]

and make it public

https://twitter.com/jneira/status/1371581513041547264

[kret]

@kret wow, that is really really great, many thanks for setup the formula and the alternative packages

I hope it is useful for others 😁
Thanks for the mention as well 😊 @carlocab - Homebrew maintainer - did most of the work though. Very helpful!

I think the next immediate step could be add homebrew as a new install method in the README and make it public (in the next release announce f.e.)

I leave that up to you 😇

moving to an official Haskell/HLS tap,

Create a new repo in the org is not a trivial task, maybe we could start to use your repo (or a different under another org, as you consider).

It can stay in my repo for now, if HLS decides take over, I can help migrate.

automating tap refresh upon new release,

that would be nice, what would be the update suppose? changing .rb files?

Yes, basically. I saw AdoptOpenJDK had something like this; we could use it as an inspiration.
https://github.com/AdoptOpenJDK/homebrew-openjdk, see the /Templates/*.tmpl, /auto_updater.sh, /.github/workflows/updater.yml, /casks.txt.

[carlocab]

single GHC version support

Formulae that builds the language server for other versions of GHC would be, in my opinion, also acceptable at Homebrew/core. (Of course, this would need to be acceptable to other maintainers too.)

For example, we used to have separate formulae that distribute essentially the same software, except one was built against Python2, and the other Python3.

[kret]

That would be great, @carlocab :)
Is there a way to ask Homebrew maintainers if they would accept such an approach before creating the formulae?

As to the how I would need help with getting the correct way to provide GHC versions for compilation:

• Is there a way to tell Cabal to fetch specific GHC for compilation?
• I see that there are ghc@8.6 (8.6.5), ghc@8.8 (8.8.4) and ghc (8.10.4) versions in Homebrew. Does it mean I should add the specific versions HLS needs as new formulae (like ghc@8.6.4, ghc@8.10.3 etc)? ...and then use these to build HLS formulae? That does not sound super exciting...

[jneira]

I see that there are ghc@8.6 (8.6.5), ghc@8.8 (8.8.4) and ghc (8.10.4) versions in Homebrew. Does it mean I should add the specific versions HLS needs as new formulae (like ghc@8.6.4, ghc@8.10.3 etc)? ...and then use these to build HLS formulae? That does not sound super exciting...

Imho i think that to have the last minor versions usually is enough for most users (if everything goes well and the last minor version is not worse than the previous one, but then the ghc formula should not be update neither)