🪄

【Mojo🔥 25.x.x】Mojoが使いやすく(？)なっていた

2025/06/21に公開

$Mojo$ 🔥のインストールが簡単に

逝者如斯夫、 $Mojo$ 🔥が注目されてから暫く経ち、今となってはその話題性も薄れ、名を聞く事さえなくなりました。 $Zenn$ に於いても、今年に入ってから一つも記事が投稿されていないようです。こうも普及しなかった理由には幾つかあるでしょうが、その一つに導入の利便ならざることがあったのではと思います。

事実、 $2025/06/20$ 現在にあっても、相変わらず $Windows$ には対応していません。 $Windows$ ユーザーが $Mojo$ 🔥を使う場合、 $WSL$ などの仮想 $OS$ や、クラウドサービスの利用を余儀なくされる状況が続いています。

以前私が実践した際には、次に示すような、 $Python$ を介したインストール手順が示されていました。

$Modular$ を導入する(curl)
$Python$ で仮想環境を作る
(その仮想環境にて) $Modular$ で以て $Mojo$ 🔥を導入する
環境変数を設定する

今こうして眷顧すれば、難しくは無くとも面倒な作業でした。現在は改善され、異なる方法が確立・示されています。また直接の言及はないものの、依然として $Python$ を介したインストールも可能です。

本記事では、紹介されている方法に加えて、言及されていない方法についても試しています。

なお、私は $Windows$ ユーザーのため、実機へのインストールはできない状況にあります。仮想環境を使えば良いとはいえ、面倒だったので、 $Modular$ のリポジトリーから $Codespace$ を作成して利用しました。本記事の実行結果は $Codespace$ によるものです。但し、適宜削除して作り直すなどの小細工はしています。

https://github.com/modular/modular

$Mojo$ 🔥のインストール方法

前提として $Mojo$ 🔥は、独立した一つのプログラミング言語開発プロジェクトによって成るものではありません。 $Modular$ という $AI$ プラットフォームを開発する上で困難に遭遇し、それを解決するものとして副次的に生まれたという背景があるそうです。詳しい経緯は $Why$ $Mojo🔥$ を参照ください。(~~私は興味なく読んでいませんが~~)

この事実から受容できることですが、 $Mojo$ 🔥には $Modular$ が必要になります。そして実際には、 $Modular$ をインストールすることで $Mojo$ 🔥が使えるようになります。即ち、現在 $Mojo$ 🔥のみをインストールする方法は存在せず、 $Modular$ をインストールする行為がそれに該当しています。

それでは、公式の情報から確認してゆきましょう。

$Pixi$ による方法(公式推奨)

$Pixi$ とは

始めに $Pixi$ とは、パッケージ管理ツールです。比類するものには次があります。

$Conda$
$Pip$
$Poetry$
$uv$

そして、次のように比較されています。

	$Pixi$	$Conda$	$Pip$	$Poetry$	$uv$	備考
$Python$ のインストール	✅	✅	❌	❌	✅	特定バージョンの $Python$ がインストールできることを言うか
多言語対応	✅	✅	❌	❌	❌	$Python$ 以外の言語への対応
$Lockfile$ 対応	✅	❌	❌	✅	✅	$Lockfile$ ：依存関係を管理するファイル
タスク実行	✅	❌	❌	❌	❌	パッケージをビルドする作業に於けるタスクを言うか
プロジェクト管理	✅	❌	❌	✅	✅	プロジェクト単位での管理ができることを言うか

参考元:

開発の上で行うインストールの影響が、プロジェクト外に及ぼされないように管理できます。この利点は、 $uv$ やその根源にある $Rust$ に馴染あらば、自ずと理解できるでしょう。実際、使用感はそれらと似たものを感じました。

要するに、本格的かつ合理的な開発を見据えたものと言えると思います。その利便性を教化したい意図でもあるのでしょうか。

$Pixi$ を導入する

install pixi

curl -fsSL https://pixi.sh/install.sh | sh

これを実行すると再起動を要求されます。~~一寸鬱陶しいですね~~。再起動後、pixiコマンドが使えるようになります。

pixiのcodespace(github)にて

$ curl -fsSL https://pixi.sh/install.sh | sh
This script will automatically download and install Pixi (latest) for you.
Getting it from this url: https://github.com/prefix-dev/pixi/releases/latest/download/pixi-x86_64-unknown-linux-musl.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 22.7M  100 22.7M    0     0  11.8M      0  0:00:01  0:00:01 --:--:-- 34.1M
The 'pixi' binary is installed into '/home/codespace/.pixi/bin'
Updating '/home/codespace/.bashrc'
Please restart or source your shell.

$ /home/codespace/.pixi/bin/pixi -V
pixi 0.48.2
$ pixi
bash: pixi: command not found

$GitHub$ $Codespace$ では、一度切断してから再接続することで、pixiコマンドが使えるようになりました。

$Google$ $Colaboratory$ では、 $Pixi$ のインストールを保持したまま再起動する方法が分かりませんでした。相変わらず、絶対パスで指定しなければ使えません。後述する別の方法で代えた方が快適と感じました。

再起動後

$ pixi -V
pixi 0.48.2

$Modular$ の導入

$Pixi$ はプロジェクト単位で管理するためでしょう、第一にプロジェクトを作成します。

$ cd # ホームに移動
$ pixi init proj_modular -c https://conda.modular.com/max-nightly/ -c conda-forge
✔ Created /home/codespace/proj_modular/pixi.toml
$ cd proj_modular/ # プロジェクトに移動

プロジェクトの中で、 $Modular$ を導入します。

modularの導入

$ pixi add modular
✔ Added modular >=25.5.0.dev2025062005,<26

プロジェクトを作らずに同コマンドを実行するとエラーになりました。

プロジェクトなくしてはできなかった

$ pixi add modular
Error:   × failed to solve the environment
  ╰─▶ Cannot solve the request because of: No candidates were found for modular *.

$Mojo$ 🔥の動作確認

$ pixi run mojo -v
Mojo 25.5.0.dev2025062005 (b0dd305c)

やはり、プロジェクト外ではエラーになります。

$ cd # ホームに移動
$ pixi run mojo -v
Error:   × could not find pixi.toml or pyproject.toml with tool.pixi at directory /home/codespace

これは不便なのではなく、プロジェクト内に閉じた管理ができている証拠です。

プロジェクト外でも使いたくば、このようにします。

$ pixi shell

(proj_modular) $ mojo -v
Mojo 25.5.0.dev2025062005 (b0dd305c)
(proj_modular) $ cd # ホームに移動
(proj_modular) $ mojo -v
Mojo 25.5.0.dev2025062005 (b0dd305c)

この使い勝手は $Python$ の仮想環境に酷似しています。

プログラムを動かしてみる

適当に $Mojo$ 🔥のプログラムを記述、実行してみましょう。

main.mojo

@fieldwise_init
struct SMember(Copyable, Movable):
    var u16Age: UInt16
    var sName: String

fn main() raises:
    var member1 = SMember(10, "塚田")
    var sDescription: String = Optional( String("age: {}, name: {}").format(member1.u16Age, member1.sName) ).or_else("parse error")
    print( sDescription )

JIT compile

(proj_modular) $ mojo main.mojo 
age: 10, name: 塚田

compile

(proj_modular) $ mojo build main.mojo
(proj_modular) $ ls
main  main.mojo  pixi.lock  pixi.toml
(proj_modular) $ ./main 
age: 10, name: 塚田

以上で、公式の推奨する $Pixi$ を用いての導入及び動作確認ができました。

以下には、直接言及されていない方法を示します。

$Pip$ による方法(単純)

$Pixi$ を使った方法は、合理的である反面、やや煩雑です。そもそも、 $Pixi$ というパッケージ管理ツールを導入すること、プロジェクトという単位を管理すること自体が手間となる場合もあります。

$Google$ $Colaboratory$ を始め、既に $Python$ のパッケージ管理ツールである $Pip$ がある場合、これを使うことができます。仮想環境へのインストールが推奨されていますが、必須ではありません。

https://docs.modular.com/max/packages

Colaboratoryとコマンド

$Google$ $Colaboratory$ 、延いては $Jupyter$ $Notebook$ では、マジックコマンドと呼ばれるものが使われます。最もよく使うものは!pipではないでしょうか。lsやmkdirのようなコマンドを使う場合、全て!を付けて!ls、!mkdirとします。

for i in range(10):
    dir_name = f"dir_{i}"
    !mkdir {dir_name}
!ls

マジックコマンドは $Python$ コードの中に直接コマンドの混入を可能にする一方、!を付けることが手間に感じることもあります。

その回避としては、コードブロックを%%shellから始めることです。

%%shell
ls

本記事ではマジックコマンドを考慮した記述はしていないため、そのままコードブロックに入力してもエラーになります。適宜読替被下度候。

pip install modular

Colaboratoryの場合

Google Colaboratoryでこれを行うと、次のような表示が出て再起動を促されます。
再起動してもmodularのインストールは失われません。しかし、ランタイムには追加されませんでした。コードブロックは已然としてPythonとして解釈されます。
Mojo🔥を実行するには、ファイルを作成して実行する必要があります。

これだけでmojoコマンドが使えるようになります。但し、 $Pip$ に関する環境変数が正しく設定されていない場合、その限りではありません。

動作確認は省略します。

$uv$ による方法(非推奨)

$uv$ は $Pip$ 等で導入します。

$ pip install uv
Collecting uv
  Downloading uv-0.7.13-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (11 kB)
Downloading uv-0.7.13-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 17.8/17.8 MB 41.0 MB/s eta 0:00:00
Installing collected packages: uv
Successfully installed uv-0.7.13
$ uv -V
uv 0.7.13

$uv$ は先の $Pixi$ 同様、プロジェクト単位で管理するためのものです。従って、プロジェクトを作るところから始めます。

プロジェクトを作る

$ uv init prj
Initialized project `prj` at `/home/codespace/prj`
$ cd prj/ # プロジェクトに移動

プロジェクトに $Modular$ を導入する

長いのでアコーディオン

$ uv add modular
Using CPython 3.12.1 interpreter at: /home/codespace/.python/current/bin/python3.12
Creating virtual environment at: .venv
Resolved 109 packages in 1.89s
Prepared 105 packages in 3m 01s
Installed 105 packages in 10.69s
 + aiohappyeyeballs==2.6.1
 + aiohttp==3.12.13
 + aiosignal==1.3.2
 + annotated-types==0.7.0
 + anyio==4.9.0
 + asgiref==3.8.1
 + attrs==25.3.0
 + certifi==2025.6.15
 + cffi==1.17.1
 + charset-normalizer==3.4.2
 + click==8.2.1
 + deprecated==1.2.18
 + exceptiongroup==1.3.0
 + fastapi==0.115.13
 + filelock==3.18.0
 + frozenlist==1.7.0
 + fsspec==2025.5.1
 + gguf==0.17.1
 + googleapis-common-protos==1.70.0
 + grpcio==1.73.0
 + grpcio-reflection==1.71.0
 + grpcio-tools==1.71.0
 + h11==0.16.0
 + hf-transfer==0.1.9
 + hf-xet==1.1.4
 + httpcore==1.0.9
 + httpx==0.28.1
 + huggingface-hub==0.33.0
 + idna==3.10
 + importlib-metadata==8.6.1
 + jinja2==3.1.6
 + markupsafe==3.0.2
 + max==25.4.0
 + modular==25.4.0
 + mpmath==1.3.0
 + msgspec==0.19.0
 + multidict==6.5.0
 + networkx==3.5
 + ninja==1.11.1.4
 + numpy==2.3.0
 + nvidia-cublas-cu12==12.6.4.1
 + nvidia-cuda-cupti-cu12==12.6.80
 + nvidia-cuda-nvrtc-cu12==12.6.77
 + nvidia-cuda-runtime-cu12==12.6.77
 + nvidia-cudnn-cu12==9.5.1.17
 + nvidia-cufft-cu12==11.3.0.4
 + nvidia-cufile-cu12==1.11.1.6
 + nvidia-curand-cu12==10.3.7.77
 + nvidia-cusolver-cu12==11.7.1.2
 + nvidia-cusparse-cu12==12.5.4.2
 + nvidia-cusparselt-cu12==0.6.3
 + nvidia-nccl-cu12==2.26.2
 + nvidia-nvjitlink-cu12==12.6.85
 + nvidia-nvtx-cu12==12.6.77
 + opentelemetry-api==1.31.1
 + opentelemetry-exporter-otlp-proto-common==1.31.0
 + opentelemetry-exporter-otlp-proto-http==1.31.0
 + opentelemetry-exporter-prometheus==0.52b1
 + opentelemetry-proto==1.31.0
 + opentelemetry-sdk==1.31.1
 + opentelemetry-semantic-conventions==0.52b1
 + packaging==25.0
 + pillow==11.2.1
 + prometheus-async==25.1.0
 + prometheus-client==0.22.1
 + propcache==0.3.2
 + protobuf==5.29.5
 + psutil==7.0.0
 + pycparser==2.22
 + pydantic==2.11.7
 + pydantic-core==2.33.2
 + pydantic-settings==2.9.1
 + pyinstrument==5.0.2
 + python-dotenv==1.1.0
 + python-json-logger==3.3.0
 + pyyaml==6.0.2
 + pyzmq==27.0.0
 + regex==2024.11.6
 + requests==2.32.4
 + safetensors==0.5.3
 + scipy==1.15.3
 + sentencepiece==0.2.0
 + sentinel==1.0.0
 + setuptools==80.9.0
 + sniffio==1.3.1
 + soundfile==0.13.1
 + sse-starlette==2.3.6
 + starlette==0.41.2
 + sympy==1.14.0
 + taskgroup==0.2.2
 + tiktoken==0.9.0
 + tokenizers==0.21.1
 + torch==2.7.0
 + tqdm==4.67.1
 + transformers==4.52.4
 + triton==3.3.0
 + typing-extensions==4.14.0
 + typing-inspection==0.4.1
 + urllib3==2.5.0
 + uvicorn==0.34.3
 + uvloop==0.21.0
 + wrapt==1.17.2
 + xgrammar==0.1.19
 + yarl==1.20.1
 + zipp==3.23.0

仮想環境を有効にする

uv addを実行すると、.venvの名で自動的に仮想環境が作られます。mojoはこの仮想環境内にインストールされているため、これを有効にすることが最も単純な方法でしょう。

$ source .venv/bin/activate
(prj) $ mojo -v
Mojo 25.4.0 (fbeca2fa)

$Python$ の仮想環境を有効にしなければ $Mojo$ 🔥が使えない状態です。これでは、嘗ての状況と変わりません。

跋

三つの方法で $Mojo$ 🔥のインストールを確認しました。所感としては、嘗てのcurl→ $Python$ →環境変数に比べたらまし、という程度です。最も簡単なのは $Pip$ によるものであろうと思います。

とは言え、 $Pixi$ にせよ、 $Pip$ にせよ、 $Mojo$ 🔥と直接関係あるものではありませんし、そもそも $Modular$ という $AI$ プラットフォームに依存しています。そうした点が、 $Mojo$ 🔥に手を出しづらくしている要因の一つであるとも改めて感じました。

また言語の思想が $Python$ と大きく異なっている点も、その後の学びづらさとして普及を阻害している側面はあるかもしれません。 $Rust$ の方が或る意味では似ているように思います。それならば $Rust$ でよいのでは？という指摘も出てしまうでしょう。

$Mojo$ 🔥が日本で一定の普及を見ることはあるのでしょうか。

Mojo🔥のインストールが簡単に

Mojo🔥のインストール方法

Pixiによる方法(公式推奨)

Pixiとは

Pixiを導入する

Modularの導入

Mojo🔥の動作確認