Flakes 入門
flakes の実験的な機能は Nix における大きな進展です。flakes は Nix 式の間の依存関係を管理するためのポリシーを導入し、再現性、構成可能性、使いやすさを向上させることができます。flakes はまだ、実験的な機能ですが Nix コミュニティの間で広く使われています。[1]
Flakes は nix プロジェクト始まって以来最も大きな変化の1つです。[2]
簡単に説明していきます。もし JavaScript/Go/Rust/Python などの言語の経験があれば package.json
/go.mod
/Cargo.toml
/pyproject.toml
のようなファイルに親しみがあるでしょう。これらのファイルにはソフトウェアパッケージ間の依存関係とプロジェクトのビルドの仕方が記述されています。
同様に、このような言語のパッケージマネージャは依存関係のバージョンのロックをし、プロジェクトの再現性を担保するために package-lock.json
/go.sum
/Cargo.lock
/poetry.lock
のようなファイルを利用します。
Flakes は Nix のエコシステムの再現性、構成可能性、使いやすさを強化するためにこのようなパッケージマネージャから着想を得ました。
Flakes では flake.nix を導入することで、Nix パッケージ間の依存関係やプロジェクトのビルド方法を記述しています (package.json
のようなものです) 。さらに、flake.lock を用いて依存するバージョンをロックし、プロジェクトの再現性を担保しています (package-lock.json
のようなものです) 。
とはいえ、Flakes の実験的な機能は Nix 本来の設計をユーザレベルで壊すものではありません。 Flakes が導入する2つのファイル flake.nix
/flake.lock
は、他の Nix の設定の単なるラッパーに過ぎません。以降の章では、Flakes を使うことで、より便利な方法で Nix 式間の依存関係を Nix 本来の設計に基づいて管理できるようになることを見ていきます。
Flakes における注意事項 caution
Flakes の利点ははっきりとしていて、Flakes は NixOS コミュニティ全体で受け入れられてきました。現在では、半分以上のユーザが Flakes を活用していて[3]、Flakes はこれからも活用されていくでしょう。
⚠️ しかし、Flakes が未だに実験的な機能 であることは覚えておくべきです。Flakesにはいくつか問題もあり、安定化の最中に破壊的変更が行われる可能性もあります。このような破壊的変更の程度は不確かなままです。
特にこの本は NixOS と Flakes を中心として構成されていることもあり、総合的に、私は Flakes を利用することを強く推奨します。しかし、今後の破壊的変更によって起こりうる潜在的な問題へ備えることも重要です。
いつ Flakes は安定するの?
Flakes の詳細についていくらか掘り下げました。
- [RFC 0136] A Plan to Stabilize Flakes and the New CLI Incrementally: Flakes と新しい CLI の段階的な安定化の計画について(マージ済)
- CLI stabilization effort: 新しい CLI の安定化の進捗をトラックする Issue
- Why Are Flakes Still Experimental? - NixOS Discourse: Flakes が未だに実験段階と捉えられている理由についての議論が行われている投稿
- Flakes Are Such an Obviously Good Thing - Graham Christensen: Flakes の設計と開発のプロセスにおける改善できる点を指摘しつつ Flakes の利点を強調している記事
- teaching Nix 3 CLI and Flakes #281 - nix.dev: nix.dev において Nix 3.0 の CLI と Flakes を扱うべきかという Issue で、nix.dev においては、不安定な機能について積極的に扱うべきではないという結論になりました。
- Draft: 1-year Roadmap - NixOS Foundation: NixOS Foundation が提供しているロードマップで、Flakes の安定化に関する計画について言及しています。
これらの情報から、Flakes はいくらかの破壊的変更の可能性はありますが、ここ2年以内には安定するのではないかと思われます。
新しい CLI と 従来の CLI
Nix は 2020年に nix-command
と flakes
の2つの実験的な機能を導入しました。これによって、新しい command-line インターフェース (新しい CLI)、標準化された Nix パッケージの構造定義 (Flakes の機能)、cargo/npm のバージョンをロックするファイルと同様の flake.lock
のような機能といったものがもたらされています。これらの機能は Nix の潜在能力を大きく引き出すことができ、2024年2月1日時点で実験段階ですが Nix コミュニティの間で広く受け入れられています。
現在の Nix の新しい CLI (nix-command
の実験的な機能) は Flakes と強く結びついています。この CLI と Flakes を明示的に切り離そうとする運動もありますが、Flakes を使う際にはどうしても新しい CLI を使う必要があります。この本は、NixOS と Flakes の入門者向けのガイドであるので、Flakes が依存している新しい CLI と従来の CLI との違いについて解説する必要があります。
ここでは、新しい CLI (nix-command
) と Flakes を使う上で、もはや必要なくなった従来の CLI について羅列しています。これらのコマンドは、対応する新しい CLI に置き換えることができます (しかし、nix-collect-garbage
については現在代用のコマンドはありません):
nix-channel
: apt/yum/pacman のような他のパッケージ管理ツールのようにnix-channel
はソフトウェアパッケージのバージョンを stable/unstable/test チャンネルを用いて管理することができます。- Flakes では、
nix-channel
の機能はflake.nix
のinputs
セクションで完全に置き換えることができます。
- Flakes では、
nix-env
:nix-env
は従来の Nix のユーザ環境のソフトウェアパッケージを管理するための CLI ツールです。nix-channel
によって加えたデータソースからのパッケージのインストールを行います。この際、パッケージのバージョンはこのチャンネルに影響を受けます。nix-env
を用いたインストールでは Nix の宣言的な設定に自動的に記録されず、Nix の設定の制御下に置かれないので、他のコンピュータへの複製は大変になります。このことから、このコマンドを直接使用することはおすすめしません。- これに対応する新しい CLI のコマンドは
nix profile
です。ですが、個人的には入門者にはおすすめしません。
nix-shell
:nix-shell
は一時的なシェル環境を作り出すことだでき、開発やテストに便利です。- 新しい CLI では、3つのサブコマンド:
nix develop
,nix shell
,nix run
に分けられます。これらのコマンドについては、"開発環境" の章で議論していきます。
- 新しい CLI では、3つのサブコマンド:
nix-build
:nix-build
は Nix パッケージをビルドし、ビルド成果物を/nix/store
に格納します。しかし、このビルド成果物は Nix の宣言的な設定には記録されません。- 新しい CLI では
nix-build
はnix build
で置き換えられます。
- 新しい CLI では
nix-collect-garbage
: ガベージコレクションコマンドは、/nix/store
内の使われていないストアオブジェクトを一掃します。- 新しい CLI にも
nix store gc --debug
という似たようなコマンドが存在しますが、このコマンドは Nix のプロファイル世代を削除しないので完全な代用のコマンドは現在のところありません。
- 新しい CLI にも
- 他のマイナーなコマンドについてはここでは扱いません。
- nixのコマンドを解説してみるで詳細なコマンドの比較をすることができます。