Verification
Provide a detailed description of the proposed feature
Introduce a filtered/parameterized API endpoint on formulae.brew.sh that accepts a list of formula names and returns only the relevant metadata subset, instead of requiring clients to download the full formula.jws.json file (~31MB). For example: GET /api/formula/batch?names=git,wget,curl. This would complement the already-existing per-formula endpoint (/api/formula/{name}.json) by allowing multi-formula queries in a single request.
What is the motivation for the feature?
The monolithic formula.jws.json is currently ~31MB and grows as more formulae are added. It is an all-or-nothing download — any network interruption requires a full retry. Most brew operations (upgrade, info, install) only concern a small subset of the ~7000 formulae, yet every client must download the entire dataset regardless. This is inefficient on metered connections, slow networks, CI/CD pipelines, and Docker builds where bandwidth and speed matter.
How will the feature be relevant to at least 90% of Homebrew users?
Every user who runs brew update, brew upgrade or brew install triggers this download. The average user has a small number of installed packages compared to the total formula count, meaning nearly everyone downloads far more data than they actually need on every operation. Faster, leaner downloads improve the experience universally.
What alternatives to the feature have been considered?
Per-formula endpoint (/api/formula/{name}.json) already exists but making hundreds of individual requests for a typical upgrade check would be impractical and put more load on the server than a single batched request.
A third-party Python script could cross-reference installed packages against the local cached JSON to check for outdated formulae, but this is a workaround — brew itself depends on the formula JSON for version resolution, dependency trees, and available casks, so the improvement needs to be at the brew tooling and API level to benefit all users transparently.
Incremental/interrupted download tracking — brew could internally track which formulae were recently updated and resume or skip already-processed entries, avoiding redundant work on flaky connections. This is a finer-grained approach worth exploring but likely a separate and more complex effort than the batched API endpoint proposed here.
Verification
brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.Provide a detailed description of the proposed feature
Introduce a filtered/parameterized API endpoint on formulae.brew.sh that accepts a list of formula names and returns only the relevant metadata subset, instead of requiring clients to download the full formula.jws.json file (~31MB). For example: GET /api/formula/batch?names=git,wget,curl. This would complement the already-existing per-formula endpoint (/api/formula/{name}.json) by allowing multi-formula queries in a single request.
What is the motivation for the feature?
The monolithic formula.jws.json is currently ~31MB and grows as more formulae are added. It is an all-or-nothing download — any network interruption requires a full retry. Most brew operations (upgrade, info, install) only concern a small subset of the ~7000 formulae, yet every client must download the entire dataset regardless. This is inefficient on metered connections, slow networks, CI/CD pipelines, and Docker builds where bandwidth and speed matter.
How will the feature be relevant to at least 90% of Homebrew users?
Every user who runs brew update, brew upgrade or brew install triggers this download. The average user has a small number of installed packages compared to the total formula count, meaning nearly everyone downloads far more data than they actually need on every operation. Faster, leaner downloads improve the experience universally.
What alternatives to the feature have been considered?
Per-formula endpoint (/api/formula/{name}.json) already exists but making hundreds of individual requests for a typical upgrade check would be impractical and put more load on the server than a single batched request.
A third-party Python script could cross-reference installed packages against the local cached JSON to check for outdated formulae, but this is a workaround — brew itself depends on the formula JSON for version resolution, dependency trees, and available casks, so the improvement needs to be at the brew tooling and API level to benefit all users transparently.
Incremental/interrupted download tracking — brew could internally track which formulae were recently updated and resume or skip already-processed entries, avoiding redundant work on flaky connections. This is a finer-grained approach worth exploring but likely a separate and more complex effort than the batched API endpoint proposed here.