Homebrew installer

[vmlrodrigues]

Any chance you could make a Homebrew installer for Mud?

[vmlrodrigues]

Following up on my own issue — I had a go at this to see what was actually
involved, and got a working cask out of it.

homebrew-cask is out of reach for now, of course. (Worth noting the bar is
higher for you than for anyone else: self-submission wants 225 stars where a
third party needs 75.) But a tap of your own would work today and needs
nobody's approval:

brew install --cask joseph/mud/mud

What that buys people is reproducibility. Anyone who rebuilds their Mac from
a Brewfile currently has to leave Mud out and reinstall it by hand afterwards,
which is exactly the sort of thing that gets forgotten. And if Mud does clear
the bar later, the same cask file moves to homebrew-cask unchanged.

Here's one that works, in case it saves you the fiddling. Tested against
4.2.0 — brew style and brew audit --cask --online both clean, installs
and livechecks correctly:

cask "mud" do
  version "4.2.0,21"
  sha256 "ffbfa4bdd8f16b9957e73a399e7122f8470781770996bfed899612907ba04c48"

  # The appcast reports short version and build ("4.2.0 (21)"), and the
  # build number increments on every release, so the cask carries both.
  # Only the short version appears in the tag and the file name.
  url "https://github.com/joseph/mud/releases/download/v#{version.csv.first}/" \
      "Mud-v#{version.csv.first}.dmg"
  name "Mud"
  desc "Markdown viewer that renders GitHub-flavored Markdown and raw source"
  homepage "https://github.com/joseph/mud"

  livecheck do
    url "https://apps.josephpearson.org/mud/appcast.xml"
    strategy :sparkle
  end

  # Mud updates itself through Sparkle, so `brew upgrade` should leave it
  # alone unless asked with --greedy.
  auto_updates true
  depends_on macos: :sonoma

  app "Mud.app"
  # The `mud` command. Contents/Resources/mud.sh dispatches to the bundled
  # CLI at Contents/Helpers/mud for rendering flags, and to `open -a` for
  # GUI use. Only the Direct (non-App-Store) build ships these; the DMG is
  # that build. Mud's own Settings > Command Line installer writes a symlink
  # elsewhere, so use one or the other, not both.
  binary "#{appdir}/Mud.app/Contents/Resources/mud.sh", target: "mud"

  zap trash: [
    "~/Library/Application Support/org.josephpearson.Mud",
    "~/Library/Caches/org.josephpearson.Mud",
    "~/Library/Containers/org.josephpearson.Mud",
    "~/Library/Containers/org.josephpearson.Mud.QuickLook",
    "~/Library/Containers/org.josephpearson.Mud.Thumbnail",
    "~/Library/Group Containers/XVL2AFNXH5.org.josephpearson.Mud",
    "~/Library/HTTPStorages/org.josephpearson.Mud",
    "~/Library/Preferences/org.josephpearson.Mud.plist",
    "~/Library/Saved Application State/org.josephpearson.Mud.savedState",
  ]
end

The one non-obvious bit is version: it has to carry the build number,
because the appcast advertises both and livecheck returns 4.2.0,21. A
bare 4.2.0 fails audit. The rest is ordinary — auto_updates true so brew
leaves updating to Sparkle, livecheck reading the appcast you already
publish, and binary putting mud on the PATH (an alternative to
Settings → Command Line, not a companion to it).

Your release workflow already has the version, build number and DMG in hand
at tag time, so bumping the cask could be one more step there rather than
anything ongoing.

I've had it running in a personal tap while testing, so I know the recipe
works end to end rather than just on paper. Happy to hand the cask over, or
to share the tap if that's useful to anyone before you've got one of your
own.

No obligation either way — close this if a tap isn't something you want to
carry.