Skip to content

[Feature] Submit unic to homebrew-core so installs don't need brew trust #376

Closed

Description

@yeoli9

한국어

해결하려는 문제

Homebrew 6.0.0 이상은 Homebrew 조직 밖의 tap 에서 formula 를 로드하려면 brew trust 를 요구합니다 (#369). README 에 한 줄을 추가해 우회했지만, 설치 단계가 하나 늘었고 사용자가 서드파티 tap 을 신뢰하는 판단을 해야 합니다.

"Non-official taps require explicit trust by default since Homebrew 6.0.0" — docs.brew.sh/Tap-Trust

#369 는 7.0.7 에서 보고됐지만 이 요구사항이 들어온 것은 6.0.0 (2026-06-11) 입니다. 5.1.15 에 선택적 플래그로 먼저 등장했습니다.

제안하는 해결 방법

unic 을 homebrew-core 에 제출해 brew install unic 한 줄로 설치되게 합니다. 공식 tap 은 trust 검사를 받지 않습니다.

homebrew-core 의 Notability 기준 (Package Acceptance Policy):

  • 포크 30 · watcher 30 · 스타 75 중 하나
  • 리포 소유자가 직접 제출하면 포크 90 · watcher 90 · 스타 225 중 하나

현재 (2026-09-29): 스타 17 · 포크 1 · watcher 0. 기준을 넘을 때까지 이 이슈로 추적하고, 넘으면 formula PR 을 올립니다.

함께 따라오는 변경: 릴리스 파이프라인

homebrew-core 는 소스 빌드를 요구합니다. 제출은 formula PR 한 번으로 끝나지 않고 배포 방식 자체가 바뀝니다.

"It must either build from source or install portable, platform-independent output such as Java bytecode."
"A formula must build and pass its tests on the current homebrew/core continuous-integration matrix"
— docs.brew.sh/Acceptable-Formulae

현재 tap 의 formula 는 반대로 GoReleaser 가 만든 미리 빌드된 tarball 을 설치합니다:

url "https://github.com/DevopsArtFactory/unic/releases/download/v0.3.4/unic-darwin-arm64.tar.gz"
bin.install "unic", "unic-mcp"

homebrew-core 로 가면:

  • .goreleaser.yaml 의 brews: 블록이 더 이상 배포 경로가 아닙니다. 버전 업은 태그 푸시가 아니라 homebrew-core PR 흐름을 탑니다.
  • 빌드는 Homebrew CI 가 수행합니다. 릴리스 시점 통제권이 줄어듭니다.
  • unic 과 unic-mcp 를 함께 설치하는 것은 둘 다 ./cmd/ 아래라 소스 빌드로도 문제없습니다. 이 부분은 blocker 가 아닙니다.

고려한 대안

  • 현재 방식 유지 (README 의 brew trust 안내) — 동작하고, docs: add Homebrew tap trust step #370 에서 formula 범위로 좁혀 tap 전체를 신뢰하지 않아도 됩니다. 설치 단계가 하나 더 필요합니다.
  • Install Script — Homebrew 를 쓰지 않으므로 trust 단계가 없는 한 줄 설치입니다.

메모

homebrew-core 에 들어가도 기존 tap 사용자에게는 적용되지 않으므로, README 와 릴리스 노트의 brew trust 안내는 그대로 남아야 합니다. 30 일 미만 리포는 원칙적으로 제외되는데 unic 은 해당 없습니다.

추가 맥락


English

Problem

Homebrew 6.0.0 and later require brew trust before loading formulae from taps outside the Homebrew organization (#369). A README line works around it, but it adds an install step and asks users to trust a third-party tap.

"Non-official taps require explicit trust by default since Homebrew 6.0.0" — docs.brew.sh/Tap-Trust

#369 was reported from 7.0.7, but the requirement landed in 6.0.0 (2026-06-11); 5.1.15 introduced it first as an optional flag.

Proposed Solution

Submit unic to homebrew-core so brew install unic works in one step. Official taps skip the trust check.

homebrew-core Notability thresholds (Package Acceptance Policy):

  • 30 forks, 30 watchers, or 75 stars
  • 90 forks, 90 watchers, or 225 stars for a self-submission by the repository owner

Current (2026-09-29): 17 stars, 1 fork, 0 watchers. Track here until a threshold is met, then open the formula PR.

Consequence: this changes the release pipeline

homebrew-core requires building from source. Submitting is not a one-off formula PR; it changes how unic is delivered.

"It must either build from source or install portable, platform-independent output such as Java bytecode."
"A formula must build and pass its tests on the current homebrew/core continuous-integration matrix"
— docs.brew.sh/Acceptable-Formulae

The current tap formula does the opposite — it installs prebuilt GoReleaser tarballs:

url "https://github.com/DevopsArtFactory/unic/releases/download/v0.3.4/unic-darwin-arm64.tar.gz"
bin.install "unic", "unic-mcp"

Moving to homebrew-core means:

  • The brews: block in .goreleaser.yaml stops being the delivery mechanism. Version bumps go through homebrew-core PRs rather than our tag push.
  • Homebrew CI performs the build, so we control release timing less directly.
  • Shipping both unic and unic-mcp is fine from a source build since both live under ./cmd/. That part is not a blocker.

Alternatives Considered

  • Keep the current approach (README brew trust step) — works, and docs: add Homebrew tap trust step #370 narrowed it to formula scope so users need not trust the whole tap. Costs one extra install step.
  • Install Script — bypasses Homebrew, so it is a one-line install with no trust step.

Notes

Landing in homebrew-core would not help anyone already on the tap, so the brew trust guidance in the README and release notes has to stay either way. Repositories under 30 days old are normally ineligible; unic is not affected.

Additional Context

Activity

  1. YoungJinJung commented on Sep 29, 2026

    @YoungJinJung
    Contributor

    Right direction, but it is not a root-cause fix in the sense of something that changes anything soon, and it carries a cost the issue does not mention. I checked the policies rather than going on the summary.

    Two corrections to the premises

    The version is wrong: tap trust landed in Homebrew 6.0.0 (2026-06-11), not 7.x — "Non-official taps require explicit trust by default since Homebrew 6.0.0" (docs.brew.sh/Tap-Trust). #369 happened to report it from 7.0.7. I made the same mistake in #371; corrected in #370, #374, #375.

    The notability numbers are right, and the gap is large. Today: 17 stars, 1 fork, 0 watchers against a self-submission bar of 225 stars / 90 forks / 90 watchers. That is roughly 13× the current star count.

    The cost that is not in the issue: homebrew-core would take over the release pipeline

    "It must either build from source or install portable, platform-independent output such as Java bytecode."
    "A formula must build and pass its tests on the current homebrew/core continuous-integration matrix"
    — docs.brew.sh/Acceptable-Formulae

    The current formula does the opposite — it installs prebuilt GoReleaser tarballs:

    url "https://github.com/DevopsArtFactory/unic/releases/download/v0.3.4/unic-darwin-arm64.tar.gz"
    bin.install "unic", "unic-mcp"

    In homebrew-core that becomes a source build run by Homebrew CI, which means the brews: block in .goreleaser.yaml stops being the delivery mechanism and version bumps go through homebrew-core PRs on their cadence rather than our tag push. Shipping both unic and unic-mcp is fine from source since both are under ./cmd/, so that part is not a blocker — but this is a change to how we release, not a one-off formula submission. Worth knowing before someone starts the PR expecting it to be paperwork.

    Is the trust step actually the problem?

    Homebrew added it deliberately as a control on third-party code. A user installing unic is choosing to run third-party software; being asked to say so once is arguably the feature working. The friction is one command, one time, and #370 narrowed it to formula scope so it is not even an open-ended grant.

    It also would not help anyone who has already tapped, and the README and release-note guidance has to stay either way for people on the existing tap.

    Suggestion

    Keep this open as a tracking issue — the scoping ("revisit when notable") is correct and this is the only way to remove the step within Homebrew. I would add the build-from-source consequence to the body so it is not discovered mid-PR, and fix 7.x to 6.0.0.

    But I would not treat install friction as the thing holding unic back at 17 stars. If it is worth reducing now, the install script is already a zero-trust one-liner and could simply be listed first in the README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions