🚅

anyenvをやめて良かった!asdf移行でシェル起動のイライラ解消

2024/09/20に公開

はじめに

この記事は、複数のプログラミング言語や開発ツールを扱っているエンジニアや、開発環境の効率化を目指す方を対象にしています。特に、anyenvを使って環境を管理しているものの、シェルの起動が遅い、もしくは管理が煩雑だと感じている方に向けて、asdfへの移行を紹介します。

私自身、以前はanyenvを使用していましたが、シェル起動時間の遅延や管理の複雑さに不満を感じ、最終的にasdfへ乗り換えました。この記事では、その移行理由、手順、asdfのメリットについて解説します。

読者の対象

  • 複数のプログラミング言語や開発ツールを管理しているエンジニア
  • anyenvを使っているが、シェルの起動速度や管理の煩雑さに不満を感じている方
  • 一元管理できるバージョン管理ツールを探している方

筆者の環境

  • 機種: MacBook Pro
  • CPU: Apple M2 Pro
  • メモリ: 16GB
  • macOS: Sonoma 14.3.1
  • 設定ファイル: .zshrc

anyenvを使用していたことのデメリット

  • シェル起動時の遅延問題
  • 一元管理できる開発ツールが少ない

遅延問題

anyenvを使っていた際、シェルの起動が遅くなっていた主な原因を振り返ります。
.zshrcに以下のコードを追加していたことで、シェルの起動に約5秒かかっていました(asdf移行後は1秒未満に改善)。

if [[ -s ~/.anyenv ]]; then
  PATH="$HOME/.anyenv/bin:$PATH"
  eval "$(anyenv init -)"
fi

anyenv initの実行が、シェル起動時に毎回読み込まれるため、結果としてシェルの立ち上がりが遅くなっていました。
この遅延が積み重なると、開発環境の立ち上げにもストレスが溜まり、作業効率に影響が出ると感じたため、より軽量でスピーディーな選択肢を模索し始めました。

管理できる開発ツールが少ない

anyenvでは、以下のバージョンマネージャー経由でしかツールを管理できません。これは、asdfと比べると圧倒的に少ないです。

% anyenv install --list
  Renv
  crenv
  denv
  erlenv
  exenv
  goenv
  hsenv
  jenv
  jlenv
  kubectlenv
  luaenv
  nodenv
  phpenv
  plenv
  pyenv
  rbenv
  sbtenv
  scalaenv
  swiftenv
  tfenv

asdfへの乗り換え

anyenvのデメリットを解消できるのがasdfになります。
asdfは、より幅広いツールや言語をサポートしつつ、軽量でシンプルな設計が魅力です。
また、複数の言語やツールを一元管理できる強力なバージョン管理ツールの側面もあります。公式および非公式のプラグインシステムを使って、幅広いツールを包括的に管理できることです。
プログラミング言語だけでなく、aws sdkやTerraformのようなインフラツールも対応しており、その柔軟性に魅力的です。

asdfの対応プラグインリスト

インストール方法

こちらを参考に進めていきます。
今回はHomebrewを使用して進めていきます。

  1. asdfのダウンロード
% brew install asdf
  1. asdfのインストール
% echo -e "\n. $(brew --prefix asdf)/libexec/asdf.sh" >> ${ZDOTDIR:-~}/.zshrc
  1. 設定ファイルの反映
% source ${ZDOTDIR:-~}/.zshrc
  1. 動作確認
    asdfコマンドを入力して、下記のような出力がされていれば、インストール完了になります。
% asdf
version: v0.14.1

MANAGE PLUGINS
asdf plugin add <name> [<git-url>]      Add a plugin from the plugin repo OR,
                                        add a Git repo as a plugin by
                                        specifying the name and repo url
asdf plugin list [--urls] [--refs]      List installed plugins. Optionally show
                                        git urls and git-ref
asdf plugin list all                    List plugins registered on asdf-plugins
                                        repository with URLs
asdf plugin remove <name>               Remove plugin and package versions
asdf plugin update <name> [<git-ref>]   Update a plugin to latest commit on
                                        default branch or a particular git-ref
asdf plugin update --all                Update all plugins to latest commit on
                                        default branch
....

移行によるデメリット

初期セットアップの手間

anyenvからasdfに乗り換える際には、環境の初期設定が必要です。特に、すでに複数のツールや言語をanyenvで管理している場合、そのすべてをasdfで再設定する手間が発生します。

非公式プラグインの信頼性

asdfには多くのプラグインがありますが、一部は非公式のものも含まれています。非公式プラグインは、メンテナンスが十分に行われていなかったり、互換性に問題がある場合があるため、注意が必要です。

学習コスト

asdfはanyenvに比べて柔軟性が高い分、操作や設定に少し慣れが必要です。新しいコマンドや設定方法を学ぶ必要があるため、最初のうちは少し戸惑うかもしれません。
また、anyenvでは、バージョン管理マネージャ経由で開発ツールをインストールしていましたが、asdfはその概念がなくなるため、少し違和感があります。

開発ツールのインストール例(nodeのインストール)

asdfはバージョン管理マネージャを使用せず、プラグインとしてツールをインストールします。その為、コマンドに少し差が出てきます。
nodeインストールを例を記します。

anyenvの場合

  1. バージョン管理マネージャの検索
    anyenv install --list
  2. バージョン管理マネージャのインストール
    anyenv install nodenv
  3. バージョン管理マネージャ経由でnodeのインストール
    nodenv install x.x.x
  4. インストールしたnodejsを反映
    nodenv global x.x.x
  5. インストールしたnodejs一覧を確認
    nodenv versions

asdfの場合

  1. プラグインの検索
    asdf plugin list all or 公式サイトを参照
  2. nodejsプラグインのインストール
    asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
  3. nodejsをインストール
    asdf install nodejs x.x.x
  4. インストールしたnodejsを反映
    asdf global nodejs x.x.x
  5. インストールしたnodejs一覧を確認
    asdf list

asdfによるプロジェクト管理

anyenvではnodenvやpyenvでは、プロジェクトごとにそれぞれの言語バージョンを管理するために、.node-versionや.python-versionといった個別のファイルが作成されていました。

.
├── .node-version
|     ```x.x.x```
└── .python-version
      ```x.x.x```

これに対して、asdfを使用することで、.tool-versionsという一つのファイルに複数のツールのバージョンをまとめて記述できるため、一元管理が可能です。

例えば、asdf local nodejs x.x.xを使用すると、Node.jsのバージョン指定が.tool-versionsファイルに反映されます。
このファイルには他のツール(例: Python、Rubyなど)も含めて記載できるため、プロジェクト全体の依存関係を一か所で管理できるメリットがあります。

<利用例>
.tool-versionsファイル内では以下のように複数のツールを管理できます。

.tool-verions
nodejs 16.3.0
python 3.9.1
ruby 2.7.2

これにより、プロジェクトの依存関係を簡単に確認・管理することが可能です。

移行基準

anyenvからasdfへの移行を検討する際の基準として、以下のポイントを考慮して、以降の是非を問いてみてください。

シェルの起動速度に不満がある場合

anyenvのように、複数のバージョン管理ツールを導入している場合、シェルの起動に時間がかかることがあります。asdfでは、この起動速度を劇的に改善できる可能性があるため、シェルの応答速度が課題となっている場合は移行を検討すべきです。

複数の言語やツールを一元管理したい場合

nodenvやpyenvでは、それぞれの言語バージョンを個別のファイルで管理しますが、asdfでは .tool-versions ファイルを使用して、プロジェクト全体の依存関係を一つのファイルで管理できます。複数のツールを扱うプロジェクトにおいて、よりシンプルに管理したい場合に移行を検討できます。

プラグインの豊富さが必要な場合

asdfのプラグインは非常に豊富で、言語だけでなく、開発ツール(例: aws sdk、Terraformなど)も対応しており、幅広いニーズに応えられる点が魅力です。特定のツールやフレームワークのバージョン管理も一緒に行いたい場合、asdfが適しています。

まとめ

結果的にシェルの起動速度が5秒から1秒未満に大幅に改善されました。また、AWS SDKなども一元管理ができ、言語やツールごとに別々のバージョン管理ツールを使用する必要がなくなり、環境の統一性が向上しました。

asdfへの移行は、シェルの起動速度の向上と、AWS SDKのようなツールの一元管理という大きな利便性を提供してくれます。anyenvでは、複数のバージョン管理ツールを使い分けることで起こっていた遅延や管理の煩雑さが、asdfによって一つのツールで解決できるようになりました。

この移行により、開発環境はよりスムーズかつシンプルになり、プロジェクトごとに異なるツールや言語のバージョン管理を効率的に行うことが可能となります。複数の言語やツールを頻繁に使う開発者にとって、asdfは非常に有用な選択肢かと思いました。

Discussion