mise( 「ミーズ」と読むらしい )を使ってみた(WSL2 + Ubuntu 24.04 環境)
miseって何？
いろんな種類のもののバージョンを複数インストールして
自動切換えできるような環境のようだ。
該当のフォルダへ移動するだけで、自動で切り替わる
使い方ができるらしい。
開発作業している場所によって、ツールのバージョンを切り替えられたら便利である。
たとえば、node.jsに限定すれば、nodebrewがバージョンを切り替えなど行えるが、
miseは、様々なもので(node.jsも含めて)バージョンを切り替えができて、
該当のフォルダに移動するだけで、それごとに、自動的に切り替えられるとのこと。
過去にasdfというものがあり、同じようなことができたらしい（知らんけど）
miseは、Rustで作られ、asdfよりも高速に同内容のことができるとのこと。
asdfからmiseへの移行が進んでいるとのことらしい（知らんけど）
経緯
go言語の環境をインストールしたかった。
最初、WSL2 + Ubuntu 24.04 環境で、aptでgoをインストールしようと思ったが、
それだと、最新版のgoが入らないとのこと。
curlなどで落としてきてインストールしたら最新版のgoが入るらしいが、それだと、
後々に、管理がメンドイことになると思った。
いろいろ、調べると、miseを使うと最新版のgoを簡単にインストールできることがわかった。
そのときに、miseって、そもそも、何？って、疑問に思って調べた。
まず、miseをインストールした
に、
があった。
「WSL2 + Ubuntu 24.04 環境」だから図の
「Debian/Ubuntu(apt)」のタブにある
sudo apt update -y && sudo apt install -y gpg sudo wget curl
sudo install -dm 755 /etc/apt/keyrings
wget -qO - https://mise.jdx.dev/gpg-key.pub | gpg --dearmor | sudo tee /etc/apt/keyrings/mise-archive-keyring.gpg 1> /dev/null
echo "deb [signed-by=/etc/apt/keyrings/mise-archive-keyring.gpg arch=amd64] https://mise.jdx.dev/deb stable main" | sudo tee /etc/apt/sources.list.d/mise.list
sudo apt update
sudo apt install -y mise
を実行した。
その後、
which miseと、mise -vでインストールできてることを確認した。
$ which mise
/usr/bin/mise
$ mise -v
_ __
____ ___ (_)_______ ___ ____ ____ / /___ _________
/ __ `__ \/ / ___/ _ \______/ _ \/ __ \______/ __ \/ / __ `/ ___/ _ \
/ / / / / / (__ ) __/_____/ __/ / / /_____/ /_/ / / /_/ / /__/ __/
/_/ /_/ /_/_/____/\___/ \___/_/ /_/ / .___/_/\__,_/\___/\___/
/_/ by @jdx
2025.5.3 linux-x64 (2025-05-09)
「~/.bashrc」への追記
~/.bashrc の末尾に下記のものを追記した
# 2025/05/13
# for mise
eval "$(mise activate bash)"
source ~/.bashrc
または、ログインのし直し
をやった後
mise doctor
を打ち込むと
$ mise doctor
version: 2025.5.3 linux-x64 (2025-05-09)
activated: yes
shims_on_path: no
・
・
(中略）
・
・
settings:
No problems found
上記のとおりとなった。
activatedがyesで、shims_on_pathがno
の構成であればよい。
activated、shims_on_pathの両方がyesは推奨されていないとのこと
いずれかをyesにする構成にすべきとのことだが、
activatedをyesにするのが、モダンなやり方で、推奨されているとのこと。
shims_on_pathは古い規格でレガシーな規格との互換性を重視する場合に使うとのことだが
詳しいことは、知らない。
miseでgoをインストールした
$ mise install go@latest
mise go@1.24.3 ✓ installed
miseを通じてgoをインストールした。
2025/05/14現在
「go@1.24.3」がインストールされたようだ。
特定のフォルダで「mise use」して、mise.tomlを自動生成
mise installは、どこのフォルダでも実行できる
mise installすると$HOME配下に実態がインストールされる
たとえば、
先ほど、mise install go@latest の結果、
go@1.24.3がインストールされたが、
$HOME/.local/share/mise/installs/go/1.24.3/bin/go
のような位置にインストールされた
mise useは、特定のディレクトリに移動してから実行する。
たとえば、直下に「.git」が置いてるアプリ開発用の作業ディレクトリのルート
などで、「mise use なにがし」を実行する
この「なにがし」は、あらかじめ、「mise install」しているものであることが必要。
さもなくば、エラーになる。
「mise use なにがし」を実行時に、その「なにがし」を、未だインストールしてない場合は
自動的にインストールされます。
（ 当記事のコメントで、ご指摘をくれた人がいましたので、訂正しました。 )
好きな作業フォルダに移動してから
例として、
/mydev/go_lang
に移動した後、
mise use go@1.24.3
を実行すると、
$ mise use go@1.24.3
mise /mydev/go_lang/mise.toml tools: go@1.24.3
/mydev/go_lang に、mise.tomlが自動生成された。
$ cat mise.toml
[tools]
go = "1.24.3"
これで、この mise.toml が置いてる
/mydev/go_lang 以下、末端までの位置では、
go については、この 1.24.3 のバージョンとなるとのこと。
$ which go
/home/xxxxxxx/.local/share/mise/installs/go/1.24.3/bin/go
追記) Ubuntu(WSL2)でPython本体はmiseでインストールできた
作業したいフォルダで、
mise use python@latest
$ mise use python@latest
mise hint use multiple versions simultaneously with mise use python@3.12 python@3.11
mise hint installing precompiled python from astral-sh/python-build-standalone
if you experience issues with this python (e.g.: running poetry), switch to python-build by running mise settings python.compile=1
mise python@3.13.3 ✓ installed mise /for/bar/mise.toml tools: python@3.13.3
$
python@3.13.3
がインストールされたようだ ( 2025/06/03 時点 )
mise.toml
は、
[tools]
python = "latest"
になっていた
この作業フォルダは、3.13.3で固定したいため
mise.tomlの中身の記述もそうしたい
そこで、
mise use python@3.13.3
を実行した
$ mise use python@3.13.3
mise /foo/bar/mise.toml tools: python@3.13.3
先ほどインストール済なので、特にインストールのログはでない
mise.toml
は、
[tools]
python = "3.13.3"
に変更されていた。
何が嬉しいのか、あらためて、思ったこと。
まだ、miseを使い始めで詳しいことはわからず、間違ってるかもしれませんが、
現時点で、気が付いたことを書きます
★Pythonでの話★と、★LaravelでDocker環境での話★の2つの話題を例として
現時点で、思っていることを書きます。
★Pythonでの話★
たとえば、Pythonにはvenvなどの仮想環境があるから
それを使って、アプリの開発環境ごとにバージョン切り替えすればよろしいのではないか
それなら、miseは、要らないよねって、思うかもしれない。
( 一旦は、そう思ってしまうかもしれない )
それは、つまり、どういうことかというと、
あらかじめ、requirements.txt で「周辺ライブラリや、その各々のバージョン」を記載しておく。
該当のフォルダに入って、venvの環境作り、
venvをactivateした後、requirements.txtで一括でインストールする。
以後、該当のフォルダでvenv環境をactivateすれば
自動的にrequirements.txtで記載の「周辺ライブラリや、その各々のバージョン」
が使える状況になっている
いちいち、各々を「pip install なにがし」をやっていかなくても、
requirements.txtをgitで共有するなどして配布すれば、チームメンバーと環境同期ができる
しかし、ですよ！！
このvenvなどの仮想環境は、「大元のPythonの本体」のバージョンを切り替えることが
たしか、できなかったと思う。
「大元のPythonの本体」のバージョンは、PCの本体で有効になってる
そのベースは、そのまま使って、
あくまで、「周辺ライブラリや、その各々のバージョン」の部分を
各々のvenv環境ごとに、独立的に構築できるのが、
venv(ほかにも、似たようなPythonの仮想環境) の仕組みだったと記憶している。
（ おそらく、そうだと思ってる )
開発してるアプリごとに「大元のPythonの本体」のバージョンも、切り替えたい場合は、
そのたびに、毎回、PATH環境変数を編集したりするのか！？
それは、メンドイよね。
そこで、「大元のPythonの本体」のバージョンのところについて、
今回の、このmiseでアプリの開発作業フォルダに移動したら自動的に切り替わって
そして、さらに、「周辺ライブラリや、その各々のバージョン」の部分を
各々のvenv環境ごとに、独立的に構築できる
という合わせ技が使えれば、非常によろしいのではないかと、現時点では考えている
★LaravelでDocker環境での話★
docker-compose.yml＋Dockerfileの環境のときに、
PHPのバージョンも含めDockerで共有できるのではある。
開発中のアプリをローカル動作させるのは、
このDockerコンテナ内部のPHPでよい。
それでも、ホスト側にも、Dockerコンテナ内部と同じバージョンのPHPを
インストールする必要性が、個人的にはあった。
理由としては、個人的に使いたい、VSコードのプラグインを機能させるためである。
一部のプラグインは、機能させるために
ホスト側にもPHPがインストールされていることを必要としていた。
それらの一部のプラグインは、LaravelやPHPでのコードを編集する際に、
静的解析を利用したコード補完などの便利機能を提供している
そのときの静的解析にPHPの本体のインストールがホスト側にも必要なのである。
なぜなら、VSコード自体が、ホスト側で動作しているからである。
そして、そのために、ホスト側に入れるPHPは、
動作に必要なDockerコンテナ側のPHPとバージョンをあわせたものを
インストールしておくのが、開発環境の構築としては、適切であろう
と思われる。
ホスト側のPHPを利用しての静的解析した結果、コード補完などの便利機能を効かして、
コード書いても、そのPHPのバージョンが、Dockerコンテナとずれてたら、
テストしたら動かないってことになりかねないため
それらのVSコードのプラグインでの便利機能は、ちゃんとDockerコンテナ側のPHPのバージョンと
同じバージョンのホスト側のPHPを使って、機能した結果でなければならない
そういうわけで、ホスト側にも、Dockerコンテナ内と同じバージョンのPHPを個人的に
インストールしていた。
たしかに、「大元のPHPの本体」のバージョンの切り替えるツールは、PHP専用のやり方は
あったようである。
詳細は忘れたが、そのやり方を利用してインストールした記憶がある。
その「大元のPHPの本体」のバージョンの切り替えるツールは、PHP専用のものである。
たとえば、node.js専用ならば、nodebrewで切り替えられますよと同様の調子で使えるものです。
そのような、これこれに、専用のもので、バージョンを切り替えられますよ
という類のものを、それごとに、いちいち、準備するのは、甚だ、メンドイですよね。
そういう類のものは、miseに寄せて、楽したいわけじゃないですか。
この件について、ホスト側にインストールする
「大元のPHPの本体」のバージョンについても、
miseを使って、該当のアプリの開発作業フォルダに行けば自動で切り替えれれば、
なお、よしだよね。と、思った。
mise use なにがし
で、mise.tomlを自動更新して、
そのmise.toml自体を、チーム内で共有するようなやり方になるのではないか。
上記は、
あくまで直Dockerで作業中の話である。
直Dockerでなく、devcontainerの場合は、事情が異なる。
devcontainerでは、足回りはDockerを使うことになる。
devcontainerではVSコードでコンテナ側にログインして作業することが前提になっている。
「docker-compose.ymlとDockerfile」に加えてdevcontainer.jsonでも、環境調整ができる。
devcontainer.jsonでは、VSコードのプラグインで必要なものの準備も他のメンバーと同期できる。
各種プラグインが静的解析にPHPの本体を必要とするケースも、
Dockerコンテナ側のPHPの本体を使うことになる。
なぜなら、完全にVSコード自体が、Dockerコンテナにログインした状況での
VSコードで開発作業をするからだ。
したがって、devcontainerの状況では、
ホスト側のPHPの本体は全く、関与しない。なくても、問題にならない。
そういう場合は、miseは要らないだろう。
以上
miseでインストールしたもののパスをVSコードが認識してくれない問題があるらしい
VSコードで下記の設定をして、
VSコードを開くときは、必ず、ターミナルから「code .」で開くようにしとけば解決できるらしい。
まだ、はっきりと検証できてませんが、
それでも、VSコードのプラグインが、miseでインストールしたものを認識できない問題が
発生する場合があるようだ。
はっきりと検証できておらず、間違ってるかもしれませんけど。
下記のようにすれば解決できるかもしれない。（ わかったら、ちゃんと書き直す )
「code .」でVSコードを開く予定だった
プロジェクトのルートフォルダに、拡張子が「.code-workspace」のファイルを作る
例えば、ファイル名「project.code-workspace」とする。
この、project.code-workspace の中身を
{
"settings": {
"terminal.integrated.defaultProfile.linux": "bash",
"terminal.integrated.profiles.linux": {
"bash": {
"path": "/bin/bash",
"args": ["--login"]
}
}
},
"folders": [
{
"path": "."
}
]
}
にしておく
そして、
code project.code-workspace
で、VSコードを開くようにすれば
VSコードのプラグインが、miseでインストールしたものを認識できない問題
が解消するらしいとのことだが
検証できてない。間違ってるかもしれません。はっきりわかったら、ここの文章を修正します。
一応、理屈としては、
VSコード内部をbashの「ログインシェル」として動作させるという意味になり、
元のターミナルのbashでmiseでインストールしたものを認識できている設定にしているならば、
VSコードのターミナルや、各種プラグインも、miseでインストールしたものを認識できている設定できるようになる
はずであるということだが、
( まだ、miseをつかいはじめで、miseの経験が浅いため )
検証できてない。間違ってるかもしれません。はっきりわかったら、ここの文章を修正します。
ちょっと古めですが、下記のサイトもあります。
Discussion
細かい指摘で申し訳ないのですが、
mise use <tool>で<tool>がインストールされていなかった場合、自動的にインストールされます。ご指摘ありがとうございます。助かります。