Homebrewはもう古い。MacPortsという選択肢を本気で推したい
はじめに
macOSのパッケージマネージャといえば、多くの人が Homebrew を思い浮かべるだろう。「とりあえずbrew入れとけ」は、Mac開発環境構築の定番フレーズになっている。
しかし、ここで一つ問いかけたい。
本当にHomebrewがベストな選択肢なのか?
実は、Homebrewより歴史が長く、堅牢で、パッケージ数も圧倒的に多いパッケージマネージャがある。それが MacPorts だ。
PryからIRBへ。歴史は繰り返す
Rubyの世界で似たような話がある。かつて、Rubyの標準REPL(対話型実行環境)である IRB は機能が貧弱で、多くの開発者が高機能な Pry に乗り換えた。シンタックスハイライト、lsコマンド、show_source——Pryにしかない便利機能がたくさんあったからだ。
しかし、Ruby 2.7以降、IRBは劇的に進化した。インクリメンタルなシンタックスハイライト、lsコマンド、show_sourceの実装。Ruby 3.1+ではdebug gemも標準搭載。かつてPryが担っていた機能のほとんどが、標準IRBに統合された。
「Pryはもう古い、時代はIRB」
—— k0kubun's blog
パッケージマネージャの世界でも、同じことが起きている。
Homebrewは「使いやすさ」で一世を風靡した。しかし、MacPortsも着実に進化を続けてきた。そして今、改めて両者を比較すると、MacPortsの方が優れている点が多いことに気づく。
MacPortsとは
MacPortsは、2002年から続くmacOS向けのパッケージ管理システムだ。もともとはDarwinPortsという名前で、FreeBSDのPortsシステムにインスパイアされて生まれた。
Homebrewの誕生が2009年なので、MacPortsは7年先輩ということになる。
MacPortsがHomebrewより優れている5つの理由
1. 圧倒的なパッケージ数
| パッケージマネージャ | 利用可能パッケージ数 |
|---|---|
| MacPorts | 約20,000+ |
| Homebrew | 約6,000〜7,000 |
MacPortsのパッケージ数はHomebrewの約3倍。ニッチなツールや科学計算系のライブラリまで、幅広くカバーしている。「brewにないけどportにはある」というケースは意外と多い。
2. クリーンな環境管理
Homebrewは /usr/local(Apple Silicon では /opt/homebrew)にインストールする。このディレクトリは他のアプリケーションも使うため、何がHomebrewのもので何が違うのか分かりにくくなる問題がある。
一方、MacPortsは /opt/local に全てをインストールする。このディレクトリはMacPorts専用なので:
- 環境をリセットしたい →
/opt/localをまるごと削除すればOK - 何がインストールされているか →
/opt/localを見れば一目瞭然 - 他のアプリと競合しない → 完全に独立した空間
# MacPortsの環境をまるごとリセット(究極のクリーンアップ)
sudo rm -rf /opt/local
# 再インストールすれば完全にクリーンな状態に
3. ビルドのカスタマイズ(variants)
MacPortsには variants という強力なカスタマイズシステムがある。パッケージのビルドオプションを柔軟に変更できる。
# 例:ImageMagickをWebPサポート付きでインストール
sudo port install ImageMagick +webp
# 例:ffmpegをカスタムオプションでインストール
sudo port install ffmpeg +nonfree +gpl3
# 利用可能なvariantsを確認
port variants ffmpeg
Homebrewにも--with-xxxオプションはあったが、多くが廃止されている。MacPortsではパッケージ作者が用意したvariantsを通じて、ビルドを細かく制御できる。
4. 一貫した動作環境
Homebrewはシステムにインストール済みのライブラリを積極的に再利用する。これは効率的だが、macOSのバージョンによって動作が変わる可能性がある。
MacPortsは原則として自前の依存関係を使う。つまり:
- macOS Ventura でも Sonoma でも Sequoia でも同じ動作
- Apple のライブラリアップデートに影響されない
- 再現性の高い環境が手に入る
CI/CDや複数のMacで同じ環境を揃えたい場合、この一貫性は非常に大きなメリットだ。
5. レガシーサポート
Homebrewは古いmacOSのサポートをどんどん切り捨てている。一方、MacPortsは幅広いmacOSバージョンをサポートし続けている。
少し古いMacを開発マシンとして使っている人、あるいはテスト環境として古いOSを維持している人にとって、MacPortsは頼もしい味方だ。
MacPortsの使い方
インストール
公式サイトからpkgインストーラをダウンロードするのが一番簡単。
前提条件として、Xcode Command Line Toolsが必要:
xcode-select --install
pkgをインストールしたら、ターミナルを開いて確認:
port version
# => Version: 2.11.6
基本コマンド
MacPortsの基本コマンドは直感的で覚えやすい。
# MacPorts自体のアップデート
sudo port selfupdate
# パッケージを検索
port search git
# パッケージの情報を確認
port info git
# パッケージをインストール
sudo port install git
# インストール済みパッケージの一覧
port installed
# アウトデートなパッケージを確認
port outdated
# 全てのパッケージをアップグレード
sudo port upgrade outdated
# パッケージのアンインストール
sudo port uninstall git
# 使われていない依存関係をクリーンアップ
sudo port reclaim
Homebrewとのコマンド比較
| やりたいこと | Homebrew | MacPorts |
|---|---|---|
| 自身のアップデート | brew update |
sudo port selfupdate |
| パッケージ検索 | brew search git |
port search git |
| インストール | brew install git |
sudo port install git |
| アンインストール | brew uninstall git |
sudo port uninstall git |
| 一覧表示 | brew list |
port installed |
| アップグレード | brew upgrade |
sudo port upgrade outdated |
| 情報表示 | brew info git |
port info git |
| クリーンアップ | brew cleanup |
sudo port reclaim |
見て分かるように、コマンド体系はどちらも直感的で、Homebrewユーザーならすぐに移行できる。
「sudoが必要」は本当にデメリットか?
MacPortsの批判でよく聞くのが「sudoが必要」という点だ。Homebrewはユーザー権限で動作するから安全だ、という主張がある。
しかし、ちょっと考えてみてほしい:
-
/opt/localにシステムレベルでインストールする → 明示的に権限を管理 - ユーザー権限で
/usr/localに自由にインストールする → 暗黙的に権限が緩い
セキュリティの観点では、sudoを要求する方がむしろ安全という見方もできる。何をインストールするか意識的に判断する機会が生まれるからだ。
Homebrewからの移行
既にHomebrewを使っている人も、移行は難しくない。
# 1. MacPortsをインストール(公式サイトからpkgをダウンロード)
# 2. 現在のHomebrewパッケージを確認
brew list
# 3. MacPortsで同じパッケージをインストール
sudo port install git python312 node22 wget curl
# 4. PATHの優先順位を確認(MacPortsが優先されるように)
# ~/.zshrc に以下が追加されているはず
# export PATH=/opt/local/bin:/opt/local/sbin:$PATH
# 5. 動作確認
which git
# => /opt/local/bin/git
# 6. Homebrewが不要になったらアンインストール
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"
MacPortsが向いている人
- 環境のクリーンさを重視する人
- ビルドオプションを細かく制御したい人
- 科学計算・データ解析のツールを多用する人
- 複数のMacで同じ環境を再現したい人
- macOSのバージョンをまたいで一貫した動作を求める人
- セキュリティに配慮したパッケージ管理をしたい人
まとめ
Homebrewが悪いツールだとは言わない。手軽さは確かに魅力的だ。
しかし、IRBがPryの機能を取り込んで「標準で十分」になったように、MacPortsは長年の蓄積によってパッケージ数、環境管理、カスタマイズ性、安定性のすべてにおいて高い水準に達している。
「とりあえずbrew」ではなく、**「まずportを検討する」**という選択肢を持ってみてほしい。きっと、パッケージ管理に対する考え方が変わるはずだ。
Discussion
こんにちは。
Homebrew をパッケージマネージャとしてではなく、ビルド・レシピとしてみなし、自分で formula を書いてビルドすることも楽だと思いました。このような人は Homebrew が向いているでしょうか?
その観点だと、Homebrew はかなりハマると思います。
Mac だと
apt/yum 的な「配布物中心」の世界が薄い
ローカルビルド+レシピ管理の需要が強い
ので、
「Formula = ビルドレシピ」と捉えて使うのは、かなり健全な使い方だと思います。
何言ってんだか。古いのは macport でしょ。vscode は古い、これからはサクラエディタだ
みたいな
新旧の話ではなく設計思想と用途の違いですね。ちなみに最近は MacPorts も静かに再評価されてる見たいです。
MacPortsの設計思想がクリーンだという点はとても共感しました。
ただ、タイトルの「Homebrewはもう古い」という表現については、少し強めかなとも感じました。
本記事は「Pryはもう古い、時代はIRB」というタイトルを参考にされた構造だと思いますが、Pry→IRBの例は「機能的進化による置き換わり」が明確だったので、何が新しく何が古くなったのかが分かりやすい構図だった印象があります。
今回のHomebrewについての「古い」という評価は、
・設計思想のレイヤーの話なのか
・依存解決やビルド方式といった技術的仕組みの話なのか
・メンテナンス体制や品質管理の話なのか
・エコシステムの広がり方の話なのか
どの観点を指しているのかが少し気になりました。
Homebrewは公式formula数だけでなく、Tapによるサードパーティ配布の手軽さという強いエコシステムがあり、個人ツールの公開・導入のハードルの低さも含めて広く使われ続けている側面もあると感じています。
MacPortsでは、そういった個人レベルのツール配布や導入のしやすさはどのような位置づけになるのでしょうか? そのあたりの違いも含めて知れたら、より比較として理解が深まりそうだなと思いました。
ご指摘ありがとうございます。
「古い」は煽りが強すぎました。意図は“機能の置き換え”ではなく、設計思想・再現性のレイヤーの話です。
実用性やTapによる配布のしやすさは、今もHomebrewが圧倒的に強いと思っています。
MacPortsは思想はクリーンですが、個人ツール配布の手軽さではHomebrewに劣る、というトレードオフですね。