mise( 「ミーズ」と読むらしい )を使ってみた(WSL2 + Ubuntu 24.04 環境)
miseって何？
いろんな種類のもののバージョンを複数インストールして
自動切換えできるような環境のようだ。
該当のフォルダへ移動するだけで、自動で切り替わる
使い方ができるらしい。
開発作業している場所によって、ツールのバージョンを切り替えられたら便利である。
たとえば、node.jsに限定すれば、nodebrewがバージョンを切り替えなど行えるが、
miseは、様々なもので(node.jsも含めて)バージョンを切り替えができて、
該当のフォルダに移動するだけで、それごとに、自動的に切り替えられるとのこと。
補足)
miseの話からは、脱線しますが、node.jsの切り替えは、
「nodebrew」より「nvm」のほうがよさそうと後で気が付いて
「nvm」に乗り換えたときに、nvmについて
https://zenn.dev/tazzae999jp/articles/ca0c4e381a03b0
で記事を書いてますので、ご興味があれば、こちらも参照のこと。
過去にasdfというものがあり、同じようなことができたらしい（知らんけど）
miseは、Rustで作られ、asdfよりも高速に同内容のことができるとのこと。
asdfからmiseへの移行が進んでいるとのことらしい（知らんけど）
mise use なんとか@latest はバイナリが未だ、だから、エラーになる場合があって、それについては、こちらを参照
こちらを参照
経緯
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は古い規格でレガシーな規格との互換性を重視する場合に使うとのことだが
詳しいことは、知らない。
★★★★★★★★★★★★★★★★★★★
★★ Windows環境でのmiseの追記 ★★
★★★★★★★★★★★★★★★★★★★
windows環境では、
powershell 7以降の場合は、
echo $PROFILE
で表示されるパスのスクリプトに、( なければ、つくってでも )
mise activate pwsh | Out-String | Invoke-Expression
を追加する
そうすと、次回、powershellや、git bashを開きなおしたときに、
mise doctorすると、
activated: yes
になるとのこと。
ただし、上記は、powershell 5.1では、LocationChangedACtionが見つかりません
というエラーがでる。
powershell 5.1では、miseのactivated: yesが非対応であるため
shims_on_path: yes
にするしかない
その場合は、powershellで、
echo $env:LOCALAPPDATA\mise\shims
した結果、表示されたパスを、環境変数PATH に、GUIで追加したら、
(★注意：PATHに追加時は、一番上の値として追加すること。さもなくば意図しない動きになる★)
恒久的に、
次のpowershellのセッション以降 powershellでも、git bashでも、 mise doctorしたら、
shims_on_path: yes
になる。
shims_on_path: yes
は、ちょっと、切り替わりが遅いだけ(一般に数ミリ秒程度)で、activated: yes
と同じ使い方ができるものとのこと
補足
(★注意：PATHに追加時は、一番上の値として追加すること。さもなくば意図しない動きになる★)
と書いたが、これについて補足します
shims_on_path:yesで運用時に、PATH変数の値で、PCにインストールしたPythonのパスの値が
より上に書かれたら、中途半端な挙動でエラーになります
( Python以外でも他のものでも、miseでインストールした対象のものはなんでも )
ですから、
(★注意：PATHに追加時は、一番上の値として追加すること。さもなくば意図しない動きになる★)
これは、必ず、そうする必要あります。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ shims_on_path:yesにするために、追加したパスは、必ず、PATH変数の一番上を
★ キープすることを、死守しなければならない。これは鉄則です。
★ どうしても、より上に値指定したいものがあれば、それは、
★ shims_on_path: yesでmiseでの運用を絶対にしないものに限定すべきです。
★ 正確に言うと、「一番上を死守」ではなく「競合するコマンドより前に置く」
★ でよいのであるが、それだと、PATHの値が増えた時に、わかりにくいし、
★ うっかりミスが発生しそうだから、上記のように説明しているのです。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
この前提で、which pythonをしたら、必ず、表示されるのは、
一番上に、追加したそのパスが必ず表示されます。
python --versionは、
pythonの項目の記載ありmise.tomlが置いてるフォルダの配下の位置であれば
そのmise.tomlに記載のpythonのバージョンが表示されます・・・(パターン1)
そうでない場合、
PC本体にインストールしたPythonがあれば、そのバージョンが表示されますが、・・・(パターン2)
PC本体にインストールしたPythonがなければ、エラーが表示されます。・・・(パターン3)
★★★★★★★★★★★★★★★★★★★
miseでgoをインストールした
$ mise install go@latest
mise go@1.24.3 ✓ installed
miseを通じてgoをインストールした。
2025/05/14現在
「go@1.24.3」がインストールされたようだ。
補足
「mise install なにがし」よりも、「mise use なにがし」
のほうがいいです。今回の例では、「 mise use go@latest 」
さもなくば、mise.tomlが作成されない場合あるからです。
mise.tomlが作成され、そこに、該当のものや、そのバージョンが記載されているから
そのフォルダに移動しただけで、自動切換えになるので、
いきなり、一発目から「mise use なにがし」にしとけばいいでしょう。
「mise use なにがし」は、「なにがし」がなければ、インストールしたうえで、mise.tomlも作成してくれます。
特定のフォルダで「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の経験が浅いため )
検証できてない。間違ってるかもしれません。はっきりわかったら、ここの文章を修正します。
ちょっと古めですが、下記のサイトもあります。
追記「idiomatic version files」の警告を受け続けたければ
★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★★これは、重要なので、必ず、やってたほうがいいです★★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★
miseをインストールしたら、
下記のコマンドをすべて実行しておいたほうがよいと思います
mise settings add idiomatic_version_file_enable_tools python
mise settings add idiomatic_version_file_enable_tools node
mise settings add idiomatic_version_file_enable_tools ruby
mise settings add idiomatic_version_file_enable_tools go
mise settings add idiomatic_version_file_enable_tools java
mise settings add idiomatic_version_file_enable_tools terraform
mise settings add idiomatic_version_file_enable_tools crystal
mise settings add idiomatic_version_file_enable_tools elixir
mise settings add idiomatic_version_file_enable_tools yarn
ひとおり、実行し、下記で設定できたかを確認する。
$ mise settings get idiomatic_version_file_enable_tools
["crystal", "elixir", "go", "java", "node", "python", "ruby", "terraform", "yarn"]
なぜ、こんなことをしておく必要があるのか
mise 2025.10からのmiseのバージョンからは、「idiomatic version files」の警告
を "" デフォルトでは ""受けられなくなる
設定をしたものについては、その後も受けられるとのこと。
「idiomatic version files」って何？
フォルダの直下に
.python-version
などのファイルを置き、
3.12
などのバージョン番号だけ書いた状態にしておく
これが「idiomatic version files」で、
このフォルダの配下は、pythonの3.12のバージョンで作業してもらうことを
想定してますという作成者の意図です。
2025/08/03時点
私は、とあるgitHubのリポジトリからgit cloneした
そして、そのフォルダにcd コマンドで移動した瞬間
$ cd targetdir
mise WARN deprecated [idiomatic_version_file_enable_tools]:
Idiomatic version files like /foo/hoge/targetdir/.python-version are currently enabled by default. However, this will change in mise 2025.10.0 to instead default to disabled.
You can remove this warning by explicitly enabling idiomatic version files for python with:
mise settings add idiomatic_version_file_enable_tools python
You can disable idiomatic version files with:
mise settings add idiomatic_version_file_enable_tools "[]"
See https://github.com/jdx/mise/discussions/4345 for more information.
という警告メッセージが出たこれは、なんだろう？
と思った
Google翻訳で日本語にすると
mise WARN deprecated [idiomatic_version_file_enable_tools]:
/foo/hoge/targetdir/.python-version のような慣用バージョンファイルは、現在デフォルトで有効になっています。しかし、mise 2025.10.0 では、デフォルトで無効になるように変更されます。
以下のコマンドで Python の慣用バージョンファイルを明示的に有効にすることで、この警告を削除できます。
mise settings add idiomatic_version_file_enable_tools python
以下のコマンドで慣用バージョンファイルを無効にできます。
mise settings add idiomatic_version_file_enable_tools "[]"
詳細については、https://github.com/jdx/mise/discussions/4345 をご覧ください
とのことでした。
mise settings add idiomatic_version_file_enable_tools python
これを実行後、
WSL2のターミナルを開きなおして
再度
cd targetdir
をすると、
$ cd targetdir
mise WARN missing: python@3.12.11
となりました。
つまり、リポジトリ作成者の意図で、
$ cat .python-version
3.12
と書いてくれている ( これが「idiomatic version files」のようだ )
それに対して、python@3.12.11 がない
もしくは、異なるバージョンのpythonが有効になってる
事に関する警告表示をきちんと、受けれる状況となったのだ。
たしかに、targetdirの中で、
which python
しても、何も表示されない
mise WARN missing: python@3.12.11
の警告に従う形で、
$ mise install python@3.12.11
mise python@3.12.11 ✓ installed
補足
「mise install なにがし」よりも、「mise use なにがし」
のほうがいいです。今回の例では、「 mise use python@3.12.11 」
さもなくば、mise.tomlが作成されない場合あるからです。
mise.tomlが作成され、そこに、該当のものや、そのバージョンが記載されているから
そのフォルダに移動しただけで、自動切換えになるので、
いきなり、一発目から「mise use なにがし」にしとけばいいでしょう。
「mise use なにがし」は、「なにがし」がなければ、インストールしたうえで、mise.tomlも作成してくれます。
で、miseでpython@3.12.11をインストール後、
cd ..
してから、再度、
cd targetdir
をしても、今度は、警告表示されない
targetdirにて、
$ which python
/home/myUser/.local/share/mise/installs/python/3.12.11/bin/python
「idiomatic version files」ってなんて便利なんだ
作成者の意図したバージョンがそれで書かれていた時
そこに移動しただけで、
そのバージョンのものがなければ、警告を表示してくれる
これは、便利！！
しかし、mise 2025.10.0 では、デフォルトで無効になるだって！！？？
それは、嫌です。
今回は、.python-version でしたが、
python .python-version
node .node-version, .nvmrc
ruby .ruby-version, Gemfile
go .go-version, go.mod
java .java-version, .sdkmanrc
terraform .terraform-version, main.tf
crystal .crystal-version
elixir .exenv-version
yarn .yarnrc
の種類あるようです
それらで、今後も警告をうけれるようにするには、
miseをインストールした時点で、↑↑のほうにある
★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★★これは、重要なので、必ず、やってたほうがいいです★★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★
を片っ端しからやっておけばよろしいのです。
git cloneして、そのフォルダに移動したときに、
作者が、「idiomatic version files」を作ってくれていて
それにあったバージョンのものがない場合は、警告をうけて
その警告に従い、mise use なにがし
やれば、作者の意図にあった環境で、作業がおこなえる
これが、効果的に今後も働くようにするためです！！
Discussion
細かい指摘で申し訳ないのですが、
mise use <tool>で<tool>がインストールされていなかった場合、自動的にインストールされます。ご指摘ありがとうございます。助かります。