ローカル開発環境の整備: CLIパッケージマネージャー/管理ツールの利用

概要

本記事はCLIパッケージマネージャー/管理ツールの2025年の利用についての紹介です。

CLI 関係は基本的に

1. homebrew (言語ランタイム以外すべて) + *env (言語ランタイム)
2. asdf
3. mise

※2, 3でもビルドに必要なパッケージは homebrew を使っています

という経路をたどりました。

オンボーディング時の端末セットアップでインストールしてもらって、以降は主に作業レポジトリ内にあるバージョン指定ファイルによって極力同じバージョンに揃えています。

個人としてはツール含めて、プロジェクトとしてはまだ言語ランタイムだけのところも多いかなというところで、来年はプロジェクトへの整備・推進を進めて行きたいと思っています。

はじめに

パッケージマネージャー/管理ツールを使いたいモチベーションとしては会社では同じ対象を複数人で作業するので、バージョンギャップによるトラブルを防ぎたい、というのが一番大きいです。

パッケージマネージャー/管理ツールでバージョンを揃えていない場合、破壊的な変更があった前後で

「〇〇さんの環境では動くけど、△△さんの環境では動かない/エラーになる」

ということが起こりがちです。2025年発生ではないものも含みますが、過去に以下のようなことが起こりました。

• gRPC Clientのリクエスト形式変更に伴うトラブル
  • リクエストを渡す方法が変わって Pull Request の変更確認のテストができなかった
• Terraform の template plugin -> templatefile 関数への移行期のトラブル
  • macbook の CPU が Intel -> Apple Silicon への変更と重なり、 template plugin が Apple Silicon 版に対応しないまま EOL を迎えた
  • 結果、Apple Silicon mac の人は template plugin を使っている HCL をエラーなく動かすにはプラグインを自力でコンパイルして配置する必要があった
• AWS CLIのトラブル
  • 「そのサブコマンドないよ」と言われる
  • v2 でディフォルトの挙動が変わって戸惑う(確かディフォルトのPagerが less 系になった話)

これらのトラブルは場合によってはすぐに原因がバージョン違いと特定できないこともあり、時間を取られることもありました。

以降、どのような経緯を経て現状にたどり着いたのかを書いていきます。

1. homebrew + *env

利用状況

かなり前は homebrew + *.env で対応していました。

前提として関わっていたシステム数も少なかったので、それぞれで技術スタックが大きく変わることもなく、比較的対応する人も重複していたのでバージョン変更を同期して実施しやすい状態でした。

また、あまり褒められた話ではありませんが、今よりはlinter/formatterの適応に厳格ではなく、大きくずれがあればコードレビューのさいに指摘する程度の運用をしていました。

インストールフロー

以下のようなフローで対応していました。

• homebrew で以下をインストール
  • ビルドに必要なもの (例: OpenSSL, Readline 他)
  • *env
• *env で以下をインストール
  • 各言語のランタイム
• プロジェクトごとにインストール
  • ドキュメントを見て CLI は該当バージョンを homebrew で
  • ランタイムはプロジェクト中の .*-version ファイルなどを元に *env で

気になったこと/困ったこと

• homebrew
  • バージョンの切り替え・戻しが大変になるケース有
    • brew unlink & link で実施するがうまくいかない formula も
    • 古いバージョンがクリーンアップで消えていく (適当に brew cleanup するのが悪い)
    • 場合によって formula を探しに行かないといけない場合も
  • 切り替えの範囲がユーザのグローバル
    • -> *env の導入モチベーションに
• *env ( *vm )
  • (現在は落ち着きましたが) 同じ言語に対してほぼ同じ機能のものが複数あって同定に困った
  • (使用上当然ですが) 言語ランタイムごとにインストールが必要 (例: Python -> pyenv )
    • -> 統合ツール導入のモチベーションに
    • ※ ただし、この時点ではせいぜい2個程度だったので導入には至らず

2. asdf

利用状況

上記の後、仕事が少し変わって以下のような状況となり、個人的に統合ツール導入の機運が高まりました。

• 業務対象となるシステムの数や範囲が広がった
• 上記と関連して技術スタックの数が増えた ( 最大で *env を 6, 7個インストールしてました)

「個人的に」と書いたように、プロジェクト内で使うには至りませんでした。これは後述する「気になったこと/困ったこと」の理由もあるのですが、単純に以前の私がそうだったように管理対象が多くない人の方がまだ多かったからという理由が大きかったと思います。

当時の調査

調査した時点でメンテナンスが続いているもので調べて asdf と aqua が候補でした。

• asdf-vm/asdf
• aquaproj/aqua

aqua の作者の方を Terraform の GitHub Actions で見かけたこともあって当初 aqua にしようかと思っていたのですが、仕事が変わった後のプロジェクトの大半がバージョン違いの Python と Node.js で当時は両方とも aqua が対応しておらずで asdf にしました。

この記事を書くために再度 issue を追ってみたのですが、 Python は今も対応されていないようですね。

• Add Python #1128 - aquaproj/aqua-registry ※現在もOpen
• Node.js support #2996 - aquaproj/aqua-registry ※こちらは現在対応済

インストールフロー

以下のようなフローで対応しています。

• homebrew で以下をインストール
  • ビルドに必要なもの (例: OpenSSL, Readline 他)
  • asdf をインストール
• asdf で以下をインストール
  • 各言語のランタイム
  • CLI 系のツール
• プロジェクトごとにインストール
  • 基本的にはレポジトリの .tool-versions ( *-version ) を見て asdf で

気になったこと/困ったこと

同種ツールから指摘されていることですが ( aquaでの言及, miseでの言及 )

1. コマンド体系が分かりにくい
2. plugin 管理方法が緩いのでサプライチェーンアタックにつながる可能性がある

があります。

1はしばらくユーザとして使っていましたが *env を使っているユーザにとってコマンドを再学習するコストが高いと思いました。この時点では個人利用だったので大きな問題ではなかったのですが、プロジェクトの利用上は一つハードルがありそうでした。

2は年々サプライチェーンアタックが身近に感じられる事態が発生しているので年々できれば避けたいと思っています。

3. mise

ということで、現在は mise を使っています。

mise は他に

• Environemnts: direnv のようなディレクトリごとの環境変数管理機能
• Tasks: make のようなタスクランナー機能

の機能もありますが、私の場合

• Environemnts -> 1Password
  • 1日目の記事 にも Environments というよりセキュリティ対応してる機能があります
• Tasks -> プロジェクトの言語にあればそれ、なければ make を使うかと思います
  • 元々 C -> Go を書いてたので

と、他の機能は使わないかなという感じです。

おわりに

記事を書いている中で

複数人でのCLI/Infrastructure as Codeの暮らしを良くする

を見かけてかなり被っているなとは思いつつ、「自分のところだとどうした」を書くことにしました。

2025年から特にLLMとの対話/エージェント型の開発のガードレールとして様々な開発ツールをインストールする機会も増えてきたと思います。今は個人の用途に留めていますが、来年はプロジェクトでも利用できるようにしていきたいと思っています。