Homebrew 6.0.0 リリース
(brew.sh)- すべてのメタデータを単一ダウンロードにまとめる内部 JSON APIがデフォルトに切り替わり、更新の高速化とネットワーク通信の削減を実現
- 既存の
HOMEBREW_USE_INTERNAL_APIオプトイン変数は deprecated 扱い
- 既存の
- Linux に Bubblewrap サンドボックスを適用し、build・test・postinstall ステップを macOS と同様に隔離実行
- ユーザー調査を反映し、ask モードが開発者のデフォルトに変更され、
brew install・brew upgrade時に依存関係の要約と確認プロンプトを表示 brew bundleでは formula の並列インストールがデフォルトで自動実行され、npm・krew 拡張および Windows のwingetサポートを追加brew leavesの約 30% 高速化など、起動・アップグレード全般で性能改善- macOS 27 (Golden Gate) の初期サポートを追加
- Intel サポート終了に伴い、2026年9月に macOS Intel
x86_64は Tier 3 となり、2027年9月に完全非対応予定
- Intel サポート終了に伴い、2026年9月に macOS Intel
- セキュリティ勧告 3件を公開（HTTPS→HTTP リダイレクト回避、
.pkgpostinstall root コード実行、/var/tmpplist 所有権奪取）し、修正 npxに似た新コマンドbrew exec、インストール済みパッケージの脆弱性を検査するbrew vulnsなどの新コマンドを追加- 共通 postinstall・flight 動作を literal DSL データとして JSON API に公開するinstall steps frameworkを導入し、単純な作業では Ruby ファイルのダウンロード・評価が不要に
- npm・PyPI などリスクの高いエコシステムにダウンロードcooldownを適用し、アップストリームの供給側セキュリティリスクを緩和
2件のコメント
Intel Mac までサポートするにはリソースも不足しており、GitHub Actions も今後はイメージを提供しなくなる予定なので、Homebrew もこれに合わせて進めるしかありません。
Hacker Newsのコメント
GitHubの @bfontaine です。2014〜2016年ごろに Homebrew のメンテナンスを手伝っていたけれど、Mikeが16年以上にわたってメンテナンスを続け、今でも新機能を出しているのを見るたびに驚かされる
たいていの Linux パッケージマネージャーは、ユーザーがインストールしたパッケージとシステムパッケージを分離できないので、ワークステーションの整理がほとんど不可能で、何を削除してよいのか判断しにくい
そのうえネイティブのパッケージマネージャーは Homebrew より更新が遅く、古いパッケージしか手に入らないことが多い
試しに Homebrew+pipx+npm から https://mise.jdx.dev/ へ OS レベルの開発環境を丸ごと移してみたが、実際かなりうまく動いている
多くのツールは GitHub Releases や対応するパッケージマネージャー（uv、pnpm、go get など）から直接インストールされるので、再パッケージ用の接着コードも不要だし、バージョンの遅れもない
任意のバージョンや複数バージョンを同時にインストールでき、作業フォルダごと・環境ごとに有効なバージョンを動的に切り替えられる
面白いことに Mise は依存関係をサポートしていないが、たいていは問題にならなかった。pnpm/uv が処理するか、静的バイナリなのでそのまま動くからだ
以前、Python アプリを Homebrew 向けにパッケージ化したとき、依存関係50個を
resourcesとして取り込み、全部をソースからビルドするか Homebrew にあるか手動で確認し、5言語分のビルドツールチェーンを依存関係として宣言し、更新のたびに CI を1時間以上待ったあげく、アップストリームの更新で「ビルド時依存ループ」が発生して Homebrew では解決不能になったことがあるだから Mise が「簡単な道」を選んで言語ごとのパッケージマネージャーに直接依存している理由は完全に理解できる
Brewfile で置き換えられなかったのは Colima と通信するのに必要な Docker CLI だけで、cask は今でも Homebrew を使っている。開発環境を試してみることを勧めたい。最近は素晴らしい新しいツールがたくさんある
Homebrew パッケージで Mise を使いたい人向けには https://github.com/kennyg/mise-zerobrew がある
ほとんどのプロジェクトはどうせ Docker を使うし、ローカルの PHP は静的解析のような Docker が不要な用途向けだ
Nix を使っているプロジェクトもいくつかあるが、Nix はほかのすべてを鼻で笑うほど強力な一方で、全体的なユーザー体験は git よりもさらに敵対的だ
自分の力量不足だったのかもしれないが、Mise では問題が起きるパッケージが多すぎた
システム全体のツールにも使ってみたが、Helix、NeoVim、RipGrep のように、だいたい最新ならよくて厳密なバージョンは気にしないツールには向いていなかった
Mise の依存関係は自動ではなく、すべて手動で定義する必要がある。並列インストールによって生じる順序問題を避けるためのものだ。たとえば
pipx:blackを使うなら、Python のインストールが終わるまで待たなければならない。これがツールのdependsオプションだこれは意図された設計だ。Mise は Homebrew や Nix のような完全なブートストラップ解ではなく、既存システムの上に載せるオーバーレイとして設計されている
そのため、Python は Brew で管理し、black は Mise で管理しても、特別な設定なしでほぼそのまま動く。この設計判断は大きな成功だったと思う。欠点のようにも聞こえるが、結局のところ、ユーザーが Mise を簡単だと感じる最大の理由かもしれない
Homebrew は 不変 Linux ディストリビューションで環境を素早くブートストラップする優れた方法だった
利用者は多くないが、https://formulae.brew.sh/analytics/os-version/365d/ によれば、Universal Blue の Bazzite（1.28%）、Bluefin（0.49%）、Aurora（0.28%）のような OS は、標準で Homebrew を同梱して提供している
関連リポジトリは https://github.com/ublue-os/brew
非 root ユーザーの典型的な状況が「XY はインストールできないが、ソースからビルドするのは自由」というのはおかしい
Homebrew、Mise、Nix がいまその空白を埋めている。Flatpak は GUI アプリ寄りで、Snap は……一応存在はしている
最初にインストールする3つは Sublime Text、Homebrew、最新の Bash。Zsh に乗り換えるつもりはない
良いツールはコンピューティングを楽しいものにしてくれる
最近 NixからHomebrewへ 戻ってきたが、大きな理由は3つある
Brewは手元で使っているパッケージのサポートがNixより良さそうに見える。Nixは一部のパッケージがあまりメンテナンスされていないように思える
Macのサポートもより良い。macOSでは一部のNixパッケージで機能が無効になっているが、そのパッケージのメンテナがテスト用のMacを持っていないからではないかと思う
ユーザー体験もより良い
もちろん、Nix環境の再現性や特定のパッケージを含むflakeを簡単に作れる能力は恋しいが、総合的にはBrewが自分を呼び戻した。それでもNixは今でも好きだし、会社でもNixを使っている
会社ではNixを何に使っているのか気になる。Nixが向いていそうな場所はいくつかあるが、正確に見極めるのが難しい
ただ、たいていは
defaultsや中間ツールを実行する程度だった結局Brewは維持しつつ、
bash_profileに冪等なsetupmac()関数を書いた。Bash 5を使っていて、ChatGPTが気の利いたdefaultsコマンドをよく知っていたので助けになったdotfilesで管理しているBrewfileと合わせて、新しいアカウントやMacのセットアップの問題はほぼ解決できたので、そういう大がかりなツールは必要ない
Homebrewは社員ではなく、完全にボランティアによって運営されている 非営利プロジェクト だ
継続的インテグレーション、将来の改善に必要なソフトウェア、ハードウェア、ホスティング費用をまかなうには資金が必要だ
すべての寄付金はユーザーのためにより良いHomebrewを作るのに使われるとのことなので、GitHub Sponsors、OpenCollective、Patreonを通じた定期的な支援を検討する価値はある
恩恵を受けているオープンソースプロジェクトにはかなり寄付してきたが、Homebrewについては深く考えたことがなかったので、これからは支援しようと思う
Homebrewに何らかの クールダウン機構 を入れられないだろうかと思う
自分のマシンに新しいコードを素早く配布してよいと信頼したいのはAppleとブラウザだけだ。ブラウザは何よりも信頼できない入力を大量に処理するからだ
それ以外のvscodeと拡張機能、npm、homebrew、自動更新するアプリは、数日待つほうが望ましい
いくつかの例外的な0-dayではクールダウンの回避が必要かもしれないが、現状でもユーザーが
brew upgradeを実行するまでは0-dayに対して脆弱なままだまた、NPM/PyPI/RubyGemsから取り込んでパッケージ化している項目のうち、この種の攻撃対象になりうるものについては、パッケージ化時と新バージョン更新PR作成時にすでにクールダウンを適用している
--minimum-release-ageやminimumReleaseAgeのような機能のことだこの種の攻撃は侵害後数日以内に検知されることが多い
Bunの例: https://bun.com/docs/pm/cli/install#minimum-release-age
brew set-channel stable/edgeのような形だ今週、Elixir 1.20の発表後に数分だけ試す時間があったが、Brewの対応が遅れていていら立った
erlとelixirは別の方法でもインストールできるし、個人的にはそちらのツールチェーンのほうが好みだが、そのときはやる価値がなかった
Brewには一部のレシピでソースオプションがある、あるいは以前はあったし、目を細めて見ればそれも基本的には解決策になる
作者がHomebrew coreにPRを出すか、自分のTapを公開する場合は例外だ。Archではこのあたりをどうしているのか気になる
Homebrewを可能にしているすべての人たちに拍手を送りたい。プロジェクト支援を検討する価値がある: https://opencollective.com/homebrew
Intelサポート終了 はかなり強引に感じる
Macをサーバーとして使う愛好家はほぼみな古いマシンを使っていて、その大半はIntelだ。Appleより1年早くサポートを失うことになる
Intelサポートの維持が大変であり、選択の問題だというのはわかるが、Homebrewはできるだけ長くIntelサポートを維持する方法を探すべきだと思う
古いMacをサーバーとして使う人たちは、丸め誤差を超えるほどの規模ではないと思う
Intelサポートが必要なら、MacPorts はLeopardまでまだ動いている
--no-quarantineフラグのサポートも削除された最近は一部のcaskにしかHomebrewを使っておらず、できるだけ避けるようにしている。CLIツールにはNix、Home-Manager、Nix-Darwinを使っている
固定できない強制アップグレードに何度もやられすぎて、個人的には Homebrew の使用をやめた。
今は Mise と MacPorts の組み合わせを使っていて、予告なしの破損や強制的な陳腐化を避けている。
しかも Mise は好きな新しいバージョンに上げられるが、Homebrew は Tap がいつアップグレードするかを待たなければならない。
llama.cppの Tap は 10 リリースごとに飛ばすことすらあるまだ Homebrew を使っている人たちのために、必要なときにだけアップグレードし、アップグレード前にユーザーへ表示するよう多くの作業が行われており、今回のリリースにも含まれている
開発ツールのインストールにはここ数年 MacPorts を使っているが、ずっと一貫していて、Python の新しいメジャーバージョンがランダムに飛び出してきて驚かされることもない。
Homebrew は MacPorts にない Firefox、Slack、Spotify のようなアプリケーションをインストールするときにだけ使っている。
もちろんここ数年、Python は uv に、nodejs は pnpm に移行しようと努めてきたので、今では自分にとって大きな問題ではないのかもしれない
毎日使っている iMac が今や Tier-3 の「失せろ」バケットに入ってしまった。
使えた短い期間は Homebrew が本当に気に入っていたが、使い続けるためにハードウェア更新のトレッドミルに乗るつもりはない