ハクソク

世界を動かす技術を、日本語で。

macOSのドットファイルは–/Library/Application Supportに入れるべきではない

2025年8月26日原文(becca.ooo)

概要

  • macOSのCLIツールが ~/Library/Application Support に設定ファイルを置く問題提起
  • 本来は XDG Base Directory Specification （~/.config）を使うべきという主張
  • 多くの人気ライブラリが誤ったデフォルトパスを採用
  • dotfileマネージャ も~/Library/Application Supportを無視
  • Apple自身のCLIツールも ~/.config を利用

macOS CLIツールの設定ファイル配置問題

  • macOSでCLIツールが ~/Library/Application Support に設定ファイルを置く事例増加
  • この挙動は ユーザー体験が悪い だけでなく、公式ドキュメントの意図とも異なる
  • 本来、CLIツールは XDG Base Directory Specification に従い、 $XDG_CONFIG_HOME （デフォルトは~/.config）を使うべき
  • ~/Library/Application Support に設定ファイルを置くのは、設計というより ライブラリのデフォルト挙動 に依存した結果
    • Pythonの platformdirs、JavaScriptの env-paths、Rustの dirs crate、Goの adrg/xdg などが該当
  • GUIアプリには適切だが、CLIツールの大半は ~/.config に置くべき

予想外の挙動とユーザー体験

  • 設定ファイルが ~/Library/Application Support にあるのは予期しない挙動
  • 多くのユーザーが XDG仕様 に慣れており、CLIツールにもそれを期待
  • Git, Emacs, Neovim, Tmux など多くのツールがXDG仕様を採用
  • 一貫性があることで システム探索性・予測性向上
  • 例外的な挙動はユーザーの 混乱と不満 を招く

dotfileマネージャの実態

  • 有名なdotfileマネージャ（ chezmoi, dotbot, yadm, rcm, GNU Stow）も ~/Library/Application Support を無視
    • 明示的に指定すれば可能だが、デフォルトでは対応しない
  • dotfile管理の目的は 複数環境間での設定ファイルの一元管理
  • ほとんどのユーザーは ~/.config に設定ファイルを期待

macOS標準ディレクトリガイドラインの誤解

  • 一部開発者が「macOS標準ディレクトリガイドライン」に従うべきと主張
  • しかし、ガイドラインは アプリ（/ApplicationsにインストールされるGUIアプリ） 向け
  • CLIツール はアプリとは定義が異なる
    • バンドルIDやアイコン、サンドボックス要件等が必要
  • ガイドライン内でも /bin はCLIバイナリ用と明記
  • ~/Library/Application Support はアプリ専用ディレクトリ
    • サブディレクトリ名もバンドルID準拠
  • CLIツールは バンドルIDを持たない ため該当しない
  • Apple自身のCLIツール（ bash, zsh, git, vim）も ~/.config を利用

~/Library/Application Supportを使うべきケース

  • 以下の2条件を満たす場合のみ ~/Library/Application Support を利用
    • /Applicationsまたは~/ApplicationsにインストールされたGUIアプリ
    • 設定ファイルを自動管理し、ユーザーが手動で編集しない場合

まとめ（TL;DR）

  • CLIツールが ~/Library/Application Support で設定ファイルを探すのは ユーザーの期待外れ
  • dotfileマネージャもこのディレクトリを デフォルトで無視
  • よくある正当化理由も CLIツールには当てはまらない
  • Apple純正CLIツールも ~/.config を利用
  • XDG Base Directory Specification の採用を強く推奨

Hackerたちの意見

私や他の人たちがdirs Rustクレートのメンテナーにこのことを指摘したけど、彼らはそうは考えてくれないんだよね。ほんとイライラする。今はxdgとknown-foldersを手動で組み合わせて使ってるよ。設定ディレクトリを取得するために、こんな感じで書いてる：[target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" use anyhow::{Context, Result}; #[cfg(windows)] fn get_config_base_dir() -> Result { use known_folders::{KnownFolder, get_known_folder_path}; get_known_folder_path(KnownFolder::RoamingAppData).context("設定ディレクトリを取得できませんでした") } #[cfg(not(windows))] fn get_config_base_dir() -> Result { let base_dirs = xdg::BaseDirectories::new().context("設定ディレクトリを取得できませんでした")?; Ok(base_dirs.get_config_home()) }

└

Rust界隈には二つのクレートが必要だと思う。@socの回答はアプリに関しては納得できるけど、記事が言ってる通り、多くの（ほとんどの？）Rustプログラムを作ってる人たちはアプリを作ってるわけじゃないから、このクレートを使うべきじゃないと思う。これは明らかにMacOSの「アプリ」だけをサポートしてるからね。

└

彼らはそうは考えてくれないんだよね だから、アプリ開発の長期的な未来はコンテナなんだ。人間的なレベルで、共通の利益のために人々を動かすのは無理だよ。https://specifications.freedesktop.org/basedir-spec/latest/ を考えてみて。XDG仕様は22年前からある。ユーザーにとって本当にメリットがあるし、実装も簡単なのに、2025年になってもTypeScriptの開発者たちが「これが『クソ』に従うのは難しすぎる」って文句言って、$HOMEにファイルを置くのを続けてるのを見ると、もう技術的な調整問題を人間の善意に訴えて解決するのは諦めたよ。唯一効果的なのは、アプリケーションをできるだけ厳しくサンドボックス化して、外部世界へのアクセスを狭いインターフェースを通じて制限することなんだ。

└

前の記憶からすると、これに関してはほとんどすべてのRustクレートで問題があると思う。これを解決する正しい方法は、仕様を修正して、ライブラリがその仕様に従うようにすることだよ。

└

なんであのsocってやつはそんなに怒ってて失礼なの？

└

アプリを作ってるわけじゃなくて、CLIツールだけど、CLIツールもアプリケーションだよね。

└

そろそろ、ルールにちゃんと従ったdirs-rsのフォークを作る時期かな。dirs-rsを使ってるライブラリは、そういうことを考えたくないから使ってるんだろうし。もし正しくやってるライブラリがあれば、シンプルなクレートの置き換えなら、きっと良い採用がされると思うよ。

└

etceteraのデフォルト設定の方が良さそうだね。https://docs.rs/etcetera/latest/etcetera/#native-strategy > choose_base_strategy()とchoose_app_strategy()は、LinuxとmacOSではXDG戦略を、WindowsではWindows戦略を使うんだ。これって、ほとんどのCLIツールや一部のGUIツールで使われてるよ。

Goの標準ライブラリも~/Library/Application Supportを使ってるよね[1]。Golangのトップの人たちのUnixの経歴を考えると、この決定には良い理由があると思うんだけど？[1] https://pkg.go.dev/os#UserConfigDir

└

UNIX、Plan 9、Infernoは、macOSと全く同じではないよ。たとえmacOSが認定されたUNIXでもね。POSIXが存在するのは、UNIX System Vから、すべてのクローンがそれぞれの道を進んだからなんだ。

あなたのバイナリが/Applicationsに置くべきなら、設定は~/Application Supportに置いてもいいよ。もし/binとかその辺にあるなら、またはデフォルトやシステム全体の設定が/etcに行くなら、設定は~/.configに置くべきだね。

└

同意！でも、ほとんど無意味だね。一般的に、単一のバイナリのCLIユーティリティは/Applicationsに置くべきじゃない。あのフォルダは.app拡張子のアプリバンドル用で、Info.plistファイルとかが入ってる。シェルで使われるPATHにも含まれてないし（デフォルトではね）。例外は、アプリバンドルに補助的なCLIユーティリティが含まれていて、それが/ApplicationsのアプリバンドルからPATHにシンボリックリンクされる場合かな。例えば、VSCodeのcode CLIツールみたいに。基本的に、純粋なCLIバイナリは/Applicationsには絶対に入らないと思うよ。

Hacker Newsで議論の続きを見る