Feedback wanted: declarative, grouped Homebrew update policies for a personal tap

[johnseth97]

I’m building a small Homebrew tap/tool called brew-watchtower for managing automatic grouped update policies and Brewfile synchronization on macOS.

The goal is not to replace brew upgrade, or run Homebrew as root. It is a thin wrapper around normal user-owned Homebrew operations that adds:

• named formula/cask groups;
• a clear distinction between unattended auto updates and interactive updates;
• per-group scheduled checks through user LaunchAgents;
• a declarative config that can live in dotfiles;
• a way to inspect exactly what dynamic selectors currently match.
• automatic synchronization of package state to a versioned Brewfile

For example:

[group foundation]
schedule=daily@05:00
formula=git,auto
formula=ripgrep,auto
formula_glob=python@*,interactive

[group security]
schedule=hourly@30
cask=tailscale-app,interactive
cask=firefox,interactive

[group gaming]
schedule=weekly@12:30
brewfile=exclude
cask=openemu,auto

In declarative mode, direct add, remove, and schedule mutations are refused; the user edits the manifest and runs groups sync.

I’m also experimenting with classifying Homebrew-declared privileged cask installers. A cask using a pkg artifact or an explicit sudo: true installer step is treated as interactive unless the user allow-lists it. This is deliberately only a signal about the cask declaratio and not a claim that Homebrew can predict everything an arbitrary application may request after first launch.

I’d appreciate feedback on a few design questions:

1. Is this a reasonable use of a third-party tap, or does it cut against Homebrew’s expected update model?
2. Is inspecting cask artifacts for pkg and explicit sudo a reasonable preflight signal?
3. Are there Homebrew APIs or conventions I should prefer over parsing cask declarations for that classification?
4. Does separating a root-owned policy/runtime from user-owned Homebrew execution create any obvious security or maintenance problems?
5. Is there a way to hook the Brewfile sync feature to run post brew-upgrade

Thank you.

[MikeMcQuaid]

1. Is this a reasonable use of a third-party tap, or does it cut against Homebrew’s expected update model?

Hard to say honestly just based on above whether it will cause you issues but: please try it out! Third-party taps exist exactly for the community to play around with ideas that may or may not ever make it into Homebrew proper.

• a declarative config that can live in dotfiles;

Brewfiles are already declarative. How does this differ?

2. Is inspecting cask artifacts for pkg and explicit sudo a reasonable preflight signal?

Yes, I think so? You may well find other cases and if you do: shout. I think it'd be desirable to have a more public API for exposing whether brew install --cask <cask> will be interactive or not. Similarly, we could probably do with some slightly more explicit documentation and/or tooling about how to use SUDO_ASKPASS to make this process non-interactive.

3. Are there Homebrew APIs or conventions I should prefer over parsing cask declarations for that classification?

Not sure what you mean by "cask declarations". If you mean Ruby code: yeh, I'd avoid that, just for avoiding your own pain and suffering 😂. The Homebrew JSON API (https://formulae.brew.sh/docs/api/) should provide everything you need here. No cask in homebrew/homebrew-cask requires instantiating the <cask>.rb file to install any more.

4. Does separating a root-owned policy/runtime from user-owned Homebrew execution create any obvious security or maintenance problems?

Maintenance: no idea. Security: the usual disclaimers about "be careful about what you're running as root".

5. Is there a way to hook the Brewfile sync feature to run post brew-upgrade

We don't really provide hooks for this directly. If this was to be a feature: I'd see it as a brew bundle one rather than a brew upgrade one. I can see the justification and benefit for brew bundle "hooks" more than brew upgrade "hooks".

Hope that helps! ❤️

[johnseth97]

• a declarative config that can live in dotfiles;

Brewfiles are already declarative. How does this differ?

Sorry if I wasn't clear, the groups.conf for watchtower is declarative, allowing you to group packages into buckets of different parameters in a repeatable way.

Watchtower only interacts with Brewfiles if a group has declared that it should be included in the Brewfiles that watchtower automatically exports

3. Are there Homebrew APIs or conventions I should prefer over parsing cask declarations for that classification?

Not sure what you mean by "cask declarations". If you mean Ruby code: yeh, I'd avoid that, just for avoiding your own pain and suffering 😂. The Homebrew JSON API (https://formulae.brew.sh/docs/api/) should provide everything you need here. No cask in homebrew/homebrew-cask requires instantiating the <cask>.rb file to install any more.

Mostly for getting insight into how brew determines when to warn that an installer may require root.

The API could make a lot more sense for first-party taps, I do wonder about compatibility with third-party taps though. It is important for watchtower to warn a user if any package on their auto update list might require root, as an installer sudo will simply hang the background update indefinitely.

5. Is there a way to hook the Brewfile sync feature to run post brew-upgrade

We don't really provide hooks for this directly. If this was to be a feature: I'd see it as a brew bundle one rather than a brew upgrade one. I can see the justification and benefit for brew bundle "hooks" more than brew upgrade "hooks".

Brew upgrade would be a strange hook, but brew install/uninstall hooks would be incredibly useful for automating brew bundle. Watchtower currently gets there on a schedule and keeps a history, but that leaves a gap when brew's installed package state is changed between watchtower runs.

Hope that helps! ❤️

It does, thank you!

[MikeMcQuaid]

Watchtower only interacts with Brewfiles if a group has declared that it should be included in the Brewfiles that watchtower automatically exports

Yeh, I guess I'm not sure I understand what's missing with Brewfiles as a declarative interface from this description?

The API could make a lot more sense for first-party taps, I do wonder about compatibility with third-party taps though.

Use brew info --json for those. It's the same output. You need Homebrew's Ruby implementation to parse Homebrew's Ruby.

brew install/uninstall hooks

Not gonna happen, sorry.

for automating brew bundle.

brew bundle already has hooks around brew install. This would be the place we add any more, not the other way around.

[johnseth97]

That makes me seriously reconsider the group-based Brewfile export. It basically just duplicates a slim Brewfile rather than adding meaningful policy, so I’ll likely remove it and keep Watchtower focused on update scheduling and handling. Feels more like I added the feature because "why not", which is never a good reason on its own.

With that change to my project in mind, the question on the install/uninstall hooks becomes irrelevant anyways.

I’ll also move the preflight implementation to brew info --json so it works consistently for installed third-party taps, and treat its result as a conservative warning rather than a guarantee of installer behavior.

[MikeMcQuaid]

@johnseth97 Nice. I've done grouped Brewfiles previously by doing if ENV["HOMEBREW_SOME_VAR"] and then you can set these variables to "hide/show" that section.

If you can't get this sudo information from brew info --json easily enough: we'd review and likely accept a PR to add this.