Neovide: [Feat] Add Homebrew support for macOS

[shaunsingh]

As someone who has to switch between Macs often, its a pain to manually download neovide every time.

There are two options with homebrew, a Formula, or a Cask

Formulas are used to install executables. The benefits with a formula would be

1. You have the option to build from source
2. If you add it as a Tap, we can store the formula in this repository, and we can allow users to build with options (e.g. --openGL)
   The drawback is that we can't ship full .app binaries, and its harder to make than a cask

Casks on the other hand are used to install prebuilt .app binaries. The benefits would be

1. Its much easier to make
2. We can ship the .app builds GitHub actions generates,

Personally I believe casks are the way to go (something like brew install --cask neovide). The only issue we would need to solve is https://github.com/Kethku/neovide/issues/447. After the app works as expected (double click to open) it should be fairly straightforward grabbing the latest release.

Keep in mind

1. With a cask you can't have separate versions (Vulcan and openGL). I think its best to wait until the openGL branch is merged into main
2. We need a static URL to pull the releases from. Personally I think we should have actions grab the latest build from a workflow and publish it under releases. Manually creating a new "stable" release might be another option
3. The Cask has to be pull-requested to Homebrew's repo. Unlike taps, we don't have as much control over it

If its fine with you, I'll get started on it

[Kethku]

Absolutely fine with me. I'm sending you a contributor invite as you've been pretty involved.

Some thoughts:

• Vulkan vs Opengl is going to become a non issue in the not too distant future as I'm really pushing to get the opengl branch merged soon. Then we will have one build anyway.
• As for the cask vs formula issue, I think a cask is the way to go as well. Building neovide can be painful, so if we can make a prebuilt binary, then I'm down. One question I have: how does it interact with m1 vs x86 macs? Do we have to build a binary with both m1 and x86 support?
• Releases: Is it possible to have a unstable and stable version of a homebrew app? We could have two urls one for the latest release (which once opengl merges I'm planning on making) and another for the current ci build.

I agree that we probably have to solve #447. But I personally don't have a mac. @j4qfrost might be able to make headway at some point, but I think they're busy working on m1 build support. Do you have any ideas what might be going wrong there?

[j4qfrost]

@Kethku I'll look this weekend. The work with M1 is pretty much done, since I confirmed that a valid arm binary was created and passes the tests.

[shaunsingh]

As for the cask vs formula issue, I think a cask is the way to go as well. Building neovide can be painful, so if we can make a prebuilt binary, then I'm down. One question I have: how does it interact with m1 vs x86 macs? Do we have to build a binary with both m1 and x86 support?

You can publish separate binaries for intel and Apple Silicon Macs, and then homebrew can detect the architecture and download the correct one (example)

Releases: Is it possible to have a unstable and stable version of a homebrew app? We could have two urls one for the latest release (which once opengl merges I'm planning on making) and another for the current ci build.

You can do this via homebrew-casks-versions. The cask submitted to the main repo would be the stable one. We can then submit a nightly build (the one that comes from the ci) to homebrew-casks-versions, and install it via brew install neovide-nightly

[j4qfrost]

It might be prudent to wait until opengl is merged, then it would be a bit less crazy to make releases on github, which will give us URLs we can link in cask.

[Kethku]

I'm finishing up some last issues with opengl. I'm hoping to get it merged sometime today

[shaunsingh]

It might be prudent to wait until opengl is merged, then it would be a bit less crazy to make releases on github, which will give us URLs we can link in cask.

I have the rest of the cask setup now, just need to add the link. Would you prefer having the CI automatically release any artifacts produced from the main branch, or would you prefer to manually release a stable build from time to time?

In my opinion, the "nightly" build is always stable enough so it shouldn't be an issue, but let me know if you prefer to keep stable and nightly separate

[Kethku]

I'm somewhat torn personally. I've observed that lots of folks use the release as the latest known stable which in the past has worked well, but then once we get close to another release I end up telling people to just go use the main branch as its fixed a lot of things since last cut.

I wonder if a "both and" would be better. I like the model some projects use where they cut releases manually as a way to highlight and explain features, but then also have a nightly build for those are feeling spicy.

[shaunsingh]

This is a sample cask for the 0.5.0 release

cask "neovide" do
  version "0.5.0"
  sha256 "6efe7d83309b5f389f5faa4f70a59ea093ae7dac0d6099aee76faef158c4a68a"

  url https://github.com/Kethku/neovide/releases/download/#{version}/Neovide.app.zip"
  name "neovide"
  desc "No Nonsense Neovim Client in Rust"
  homepage "https://github.com/Kethku/neovide"

  app  "Neovide.app"
end

We can also make it version agnostic by removing the checksum e.g.

cask "neovide" do
  version "(next major version)"
  sha256 :no_check

  url "https://github.com/Kethku/neovide/releases/download/static/link/to/download"
  name "neovide"
  desc "No Nonsense Neovim Client in Rust"
  homepage "https://github.com/Kethku/neovide"

  app  "Neovide.app"
end

Note that the above code is for the .zip files currently used in releases, once a new one is published (presumably in the .dmg format) then its as simple as adding container nested: "https://github.com/Kethku/neovide/releases/download/#{version}/Neovide.dmg"

Once the issue with macOS crashing is resolved, and an openGL release is produced, I'll pr the file to the hombrew cask repository. I tested the first example on my brew install and it works as expected