Skip to content

docs: record Homebrew API limitation blocking per-tap OS chart (#61) - #166

Open
mrbobbytables wants to merge 1 commit into
castrojo:mainfrom
mrbobbytables:docs/issue-61-descope-tap-os-chart
Open

docs: record Homebrew API limitation blocking per-tap OS chart (#61)#166
mrbobbytables wants to merge 1 commit into
castrojo:mainfrom
mrbobbytables:docs/issue-61-descope-tap-os-chart

Conversation

@mrbobbytables

@mrbobbytables mrbobbytables commented Aug 8, 2026

Copy link
Copy Markdown

Summary

Issue #61 asks for a per-tap (ublue-os-specific) OS distribution chart, sourced by aggregating formulae.brew.sh/api/analytics/os-version/{tap}/{formula}.json across ublue-os packages.

I independently re-verified the API surface before starting implementation (this is the third independent check, after the 2026-03-28 and 2026-08-08 investigations already recorded in the issue comments) and the conclusion holds:

  • formulae.brew.sh only exposes three analytics categories: install, install-on-request, build-error. There is no os-version category and no per-formula/per-tap OS-version breakdown endpoint anywhere in the public API (confirmed against Homebrew/formulae.brew.sh docs/api.md and live 404s).
  • The only per-tap grouped analytics endpoint (/api/analytics/${CATEGORY}/homebrew-core/${DAYS}.json) is scoped to homebrew-core only.
  • ublue-os/homebrew-tap and ublue-os/homebrew-experimental-tap packages are not indexed on formulae.brew.sh at all/api/formula/{name}.json returns 404 for any ublue-os package.

Given this, the feature as scoped in #61 is not buildable, and I'm not going to implement a placeholder/fake chart against data that doesn't exist. stats-go/internal/osanalytics already uses the only available endpoint (the global os-version analytics), which is why OsSection.astro is correctly titled "Linux OS Distribution (all of Homebrew)" rather than ublue-os-specific.

What this PR does

Documents this API limitation as a Project Decision in skills/SKILL.md (alongside the existing Build Pages decisions) so future agents don't re-open the same dead-end investigation a fourth time, and so the reasoning for why OsSection.astro is scoped the way it is stays discoverable.

Recommendation for #61

I don't have write access to close issues in this repo. Recommend closing #61 as not-planned/won't-fix, per the two prior investigation comments on the issue. If a per-tap signal is wanted later, it would need to come from a different source entirely (e.g. GitHub tap traffic/clone stats, already collected by stats fetch-homebrew) — not an OS-version breakdown, since none exists for third-party taps.

No functional/behavioral code changes. No tests added (docs-only change).

Independently re-verified (third check, after 2026-03-28 and 2026-08-08
prior findings) that formulae.brew.sh has no per-tap or per-formula
OS-version analytics endpoint, and that ublue-os tap packages are not
indexed on formulae.brew.sh at all. The per-tap OS distribution chart
requested in castrojo#61 is not buildable against this API.

Recording this as a project decision in skills/SKILL.md so future
agents don't re-attempt the same dead-end investigation, and no
placeholder/fake chart is implemented against non-existent data.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant