環境変数を管理する際、dotenvを使いたいという需要はどこのプロジェクトでもあると思います。
大抵はdotenvというパッケージですが、Rustプロジェクトにおいては、dotenvyを使います。
Rustプロジェクトでかつてはdotenvクレートがデファクトスタンダードでした。しかし、現在のRustエコシステムにおいて、新規プロジェクトでdotenvを採用する理由はほぼありません。
なぜ今、私たちはdotenvy(最後に 'y' が付く方)を使うべきなのか。その背景には、OSS開発における「メンテナンスの断絶」という切実な問題があります。
1. なぜ dotenv ではなく dotenvy なのか?
結論から言うと、dotenv は長期間メンテナンスが止まっており、dotenvy はその精神的後継(フォーク)として活発に開発されているからです。
メンテナンスの停滞とセキュリティ
Rustの初期から愛用されてきたdotenvクレート。しかし、dotenv クレートは、2020年頃から更新が滞り始めました。依存関係の脆弱性への対応や、新しいRustのバージョンへの最適化が行われない状態が続いたのです。
ついに建てられたメンテナーシップを移行する GitHub Issue
沢山の人が使っている中で、滞る更新。ついにはこのようなIssueが建てられました。
このIssueは、メンテナンスが滞っていることに対してユーザーが「誰かプロジェクトを引き継げないか?」と問いかけたものです。
- オーナーの不在: 元々のメンテナが多忙(あるいは関心の消失)により、プルリクエストが数年単位で放置されていた。
- 権限移譲の難しさ: オープンソースにおいて、リポジトリの書き換え権限を「見ず知らずの誰か」に渡すことのセキュリティリスクと心理的ハードルが浮き彫りになった。
- コミュニティの決断: 「このリポジトリが動くのを待つのではなく、フォーク(派生)して新しい標準を作ろう」という流れが加速した。
コミュニティの有志が手を差し伸べ、共同メンテナーへの立候補などを打診しましたが、最終的にプロジェクトが再び活発に動き出すことはありませんでした。この「沈黙」への回答として誕生したのが、コミュニティ主導のフォークである dotenvy です。
Rustの思想:なぜ「標準ライブラリ」に入らないのか
「そもそもNode.jsのように標準に近い扱いにすればいいのでは?」という疑問に対し、Rustの設計思想が壁になります。
-
ゼロコスト抽象化: Rustはランタイムを最小化したい言語です。
.envファイルをパースして環境変数に注入する処理は、実行時のオーバーヘッドになるため、言語のコア機能ではなく「外部ライブラリ」に任せるべきという考えが強いです。 -
コンパイル時 vs 実行時: Rustでは、コンパイル時に環境変数をチェックする手法(
env!マクロなど)も好まれるため、実行時にファイルを読み込むdotenvは「唯一の正解」ではありません。
2. dotenvy を使うメリット
dotenvy は単なるコピーではありません。現代のRust開発に即した改善が行われています。
- 継続的なメンテナンス: 定期的にアップデートされ、依存ライブラリも最新に保たれています。
-
名前の由来:
dotenvが使えなくなった(dead)から、"dotenv-y"(存続させる、活発な状態にする)というニュアンスが込められています。 -
互換性:
dotenvと完全な互換性があるため、移行は非常に簡単です。
3. 移行・導入ガイド
もし現在 dotenv を使っているなら、移行は数分で終わります。
以前のバージョン情報を引き継いでいるので非常にスムーズです。
Cargo.toml の変更
# Before
[dependencies]
dotenv = "0.15"
# After
[dependencies]
dotenvy = "0.15"
コードの書き換え
関数名もほぼ同じであるため、インポート部分を修正するだけです。
// Before
// use dotenv::dotenv;
// After
use dotenvy::dotenv;
use std::env;
fn main() {
// .envファイルを読み込む
dotenv().expect(".env file not found");
for (key, value) in env::vars() {
println!("{}: {}", key, value);
}
}
4. 教訓:ライブラリ選定で見極めるべきこと
今回の dotenv の件は、Rustに限らずOSSを利用する上で重要な教訓を残しました。
-
最終更新日を確認する:
crates.ioや GitHub で数年間更新がない場合は注意が必要です。 - Issue と PR の動向を見る: Issue #95 のように、ユーザーの問いかけにメンテナーが反応しているかは、そのライブラリの「健康状態」を示す最も重要な指標です。
-
フォークの存在を探す: 有名なライブラリの更新が止まった場合、必ずと言っていいほどコミュニティによるフォーク(今回で言う
dotenvy)が作成されます。
まとめ
技術選定において「枯れている(安定している)」ことと「放置されている」ことは似て非なるものです。環境変数管理のようなシンプルかつ重要な機能こそ、安全で活発な dotenvy を選ぶのが、現代のRustaceanとしての賢明な判断と言えるでしょう。
Note: 開発環境では
.envを使いつつ、本番環境(Dockerやクラウド環境)ではコンテナの機能で環境変数を注入するのが、現在のベストプラクティスです。
より複雑な設定管理(JSON, TOML, YAML, 環境変数の統合)が必要な場合は、configクレートが主流です。