Proposal: Make formula publishing less dependent on manually maintained Ruby files

[eliekh05]

Output of brew config

HOMEBREW_VERSION: 6.0.12
ORIGIN: https://github.com/Homebrew/brew
HEAD: b48c7994b5f0eed7bef532efa63cb4e4f763887a
Last commit: 2 days ago
Branch: stable
Core tap JSON: 22 Jul 06:39 UTC
Core cask tap: N/A
HOMEBREW_PREFIX: /usr/local
Homebrew Ruby: 4.0.6 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/4.0.6/bin/ruby
CPU: octa-core 64-bit kabylake
Clang: 17.0.0 build 1700
Git: 2.55.0 => /usr/local/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.7.8-x86_64
CLT: 26.3.0.0.1.1771626560
Xcode: 26.3

Output of brew doctor

brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed kegs have no formulae!
This means they were either deleted or installed manually.
You should find replacements for the following formulae:
  brew-vulns

Description of issue

I would like to discuss a possible improvement to the formula publishing workflow.

Currently, formulae combine metadata and build logic in the same Ruby file:

• homepage
• URL
• checksum
• license
• dependencies
• install logic

For small and large projects, this creates a repetitive update cycle. For example, changing a GitHub username, repository URL, release tag, or metadata requires editing the formula, pushing changes, validating, fixing checksums, and repeating the process.

Example workflow:

edit formula.rb
→ push
→ test
→ update checksum/metadata
→ push again
→ repeat

Would Homebrew consider a more declarative publishing workflow in the future?

Possible idea:

• Keep formula Ruby for complex build logic.
• Allow a simpler metadata source (YAML/TOML/JSON or another manifest).
• Generate the Ruby formula automatically.
• Treat generated formulae as build artifacts instead of the primary source.

This could reduce maintenance overhead while preserving Ruby flexibility for advanced formulae.

I understand formulae need to support complex build systems, but many modern projects only need metadata + a simple installer. A hybrid approach could make publishing easier for developers while keeping Homebrew's current capabilities.

[SMillerDev]

I strongly disagree with this proposal on multiple grounds, the main one being a duplication of the work for the volunteer maintainers of the project for limited benefit.

For small and large projects, this creates a repetitive update cycle. For example, changing a GitHub username, repository URL, release tag, or metadata requires editing the formula, pushing changes, validating, fixing checksums, and repeating the process.

Changing a GitHub username or git url happens about once a month across Homebrew, so it can't be that much of a burden. Version updates are covered by brew bump, which we strongly recommend over manual edits. So we would be optimizing there for something that maintainers see 12 times a year.

I understand formulae need to support complex build systems, but many modern projects only need metadata + a simple installer. A hybrid approach could make publishing easier for developers while keeping Homebrew's current capabilities.

I think you're very mistaken here. Even a simple installer needs configuration. Rust and Go are the two languages who need the least configuration and even they need additional arguments for about half the formulae. In addition to that you're completely overlooking:

• test blocks that validates that the software works
• service blocks that allows people to run the software as a service.
• postinstall blocks that configure the device to use the install correctly

[MikeMcQuaid]

Once we've completed the migration of all homebrew/core and homebrew/cask formula to not require post_install or *flight blocks: at least in theory they could all be implemented in JSON rather than Ruby. I doubt we'll necessarily decide to make that migration ourselves but it may be that one day we allow formula authors to create JSON instead of Ruby.