パッケージはNix Expressionで定義されます。
Nix Expressionはパッケージを作るレシピとも考えられます。
パッケージをパッケージレポジトリ（nixpkgs）か単独ファイルで管理できます。

では早速パッケージを定義するNix Expressionを確認しましょう。

{ stdenv, fetchurl }:

stdenv.mkDerivation {
  name = "hello-2.10";

  src = fetchurl {
    url = "mirror://gnu/hello/hello-2.10.tar.gz";
    sha256 = "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i";
  };

  meta = {
    description = "A program that produces a familiar, friendly greeting";
    longDescription = ''
      GNU Hello is a program that prints "Hello, world!" when you run it.
      It is fully customizable.
    '';
    homepage = http://www.gnu.org/software/hello/manual/;
    license = stdenv.lib.licenses.gpl3Plus;
    maintainers = [ stdenv.lib.maintainers.eelco ];
    platforms = stdenv.lib.platforms.all;
  };
}

Nix言語に慣れていないとかなりわかりにくいですね。 ここで大事なポイントはパッケージ定義は関数であることです。

行ごとを確認しましょう、まずは

{ stdenv, fetchurl }:

Nix言語の関数の書き方です、{と}に囲まれたのは関数の引数、:の後は関数の本体となります。

例えば、{ a, b }: a + bはaとbを足す関数にあります。

この関数の引数はstdenvとfetchurlであります 。

• stdenvはstandard environment(標準環境)の略であります、パッケージをビルドできる一般ツールを含めます。
• fetchurlはurlとハッシュで指したファイルをダウンロードできる関数、fetchurl以外にはGitHubからファイルをダウンロードするfetchFromGitHubなどの関数もあります。

では一行目はstdenvとfetchurl引数をもった関数を定義します。

次の行は

stdenv.mkDerivation {

となります。

引数で渡されたstdenvを利用します。
stdenvはセットであります（セットは一般のキーバリューデータ構造であります）。
Nix言語ではs.kはsセットのkキーのバリューを返します。
セットは{}で定義できます、例:{ a = 1; x = "foo"; }。セットは関数の頭によく似ていますが、別なものとなりますので間違わないように注意しましょう。

mkDerivationはstdenvで定義された関数です。
mkDerivationの引数は特定なキーをもったセットで、結果はderivation(導出)であります。
導出は多少わかりづらい概念であるので、今のところは簡単にパッケージレシピとビルドされたパッケージの中間的な物と考えればよいです。
ちなみに、mkDerivationのmkはmakeの略であって、mkDerivation「導出生成」と意味します。

料理の例えを続けますとこんな感じになります

{ キッチン, 買い物かご }:

料理を作る {
  # いろいろ
}

まだ二行目ですが、説明はほぼ完了しています。

のこりはmkDerivationの引数の形式だけです。

mkDerivationの引数セットに多くのオプションがあります。
すべてをわかる必要はないですが、基本をわかるとパッケージは作りやすい。

必須な項目は2つだけです:

• name: パッケージの名前(バージョンを含む)
• src: パッケージのソースファイル

一般的なmake系パッケージであれば、この2つを定義するだけで自動的にパッケージがビルドされます！

では例のパッケージでこのキーを確認しましょう:

  name = "hello-2.10";

※: Nix言語ではセット内の;はキーバリューペアのセパレーターとなります。

作るパッケージの名前はhello-2.10であると意味します。
バージョン番号と名前を分ける書き方もよく使われています、hello-2.10の場合はこのようになります。

  version = "2.10";
  name = "hello-${version}";

※: nameをversionの上に書く場合はrecキーワードを使って再帰セットと宣言する必要があります: rec { name = "hello-${version}"; version = "2.10"; }

次はsrcキーです。srcはパッケージのソースファイルを定義します。
ローカルファイルを定義する事もできますが、大抵の場合はネットからソースを取得します。

  src = fetchurl {
    url = "mirror://gnu/hello/hello-2.10.tar.gz";
    sha256 = "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i";
  };

helloの場合はsrcの値はfetchurl関数とその引数となります。
fetchurl関数はurlとハッシュを利用し、urlに該当するファイルをダウンロードして、ダウンロードしたファイルのハッシュを引数のハッシュと比較します。

ソースがあれば、Nixは標準方法でconfigureとmakeし、パッケージをビルドとインストールします。

例で残りのキーはmetaとなります。
metaはセットであって、パッケージのメタ情報を宣言します。
メタ情報はビルドに影響をほとんどしないで、主に外部ツールと連携に使われています。
ではhelloで設定されているmetaのキーを確認しましょう:

• description: パッケージの一行紹介
• longDescription: パッケージの詳細紹介
• homepage: パッケージのホームページ
• license: パッケージのライセンス
• maintainers: パッケージのメンテナ
• platforms: パッケージが対応するプラットフォーム

では最後にのう一度helloのNix Expressionを確認しましょう

# stdenvとfetchurl引数の関数を定義
{ stdenv, fetchurl }:

# stdenv.mkDerivation関すを呼び出し、セットを引数で渡します
stdenv.mkDerivation rec {

  # パッケージ名とバージョン
  name = "hello-2.10";

  # ソースファイルをfetchurl関数で取得
  src = fetchurl {
    # rec で再帰セットを使うためにnameキーを参照できます
    url = "mirror://gnu/hello/${name}.tar.gz";
    sha256 = "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i";
  };

  # パッケージのメタ情報
  meta = {
    description = "A program that produces a familiar, friendly greeting";
    longDescription = ''
      GNU Hello is a program that prints "Hello, world!" when you run it.
      It is fully customizable.
    '';
    homepage = http://www.gnu.org/software/hello/manual/;
    license = stdenv.lib.licenses.gpl3Plus;
    maintainers = [ stdenv.lib.maintainers.eelco ];
    platforms = stdenv.lib.platforms.all;
  };
}

helloはとても単純なパッケージであって、標準ビルドにすべておまかせしてもビルドできますがそう簡単に行かないパッケージも多くあります。
そのためmkDerivationに渡すセットにはたくさんなオプションがあります。(ドキュメンテーション)

すべてのオプションを説明すると逆に混乱するので、まずは基本の仕組みを紹介します。

ビルドはフェーズで別れています。書くフェースはビルドの一つの段階を管理します。

標準フェーズは:

• 解凍フェース(unpackPhase): ソースファイルを解凍するフェーズ
• パッチフェーズ(patchPhase): ソースファイルをパッチするフェーズ
• 設定フェーズ(configurePhase): ソースファイルをビルド準備します、デフォルトでは./configureを実行します。
• ビルドフェーズ(buildPhase): ソースファイルをコンパイルします、デフォルトではmakeを実行します。
• チェックフェーズ(checkPhase): doCheckキーがtrueの場合はビルドをチェックします、デフォルトでは実行されないフェーズ。
• インストールフェーズ(installPhase): Nixストアにパッケージをインストールするフェーズ、デフォルトではmake installを実行します。
• フィックスフェーズ(fixupPhase): パッケージにNix専用の修正をします。
• 配布フェーズ(distributionPhase): doDistキーがtrueの場合に配布用のファイルを作成するフェースです、デフォルトでは実行されません。

すべてのフェーズはフェーズ熟考前とフェーズ実行後のフックがあります、例えばunpackPhaseの場合はpreUnpackとpostUnpackが利用できます。

各フェーズには専用なキーもあります、その中でよく使うものは

• patchPhase:

  • patches: 当てるパッチの配列です、ローカルファイルとネットワークからダウロードするファイルを利用できます

    ```
    patches = [ ./my-patch.patch (fetchpatch { name = ...; url = ...; sha256= ...; }) ];
    ```
    

• buildPhase:

  • makeFlags: makeに渡すフラグ

    ```
    makeFlags = [ "-DBUILD_icons=TRUE" "-DBUILD_plasma=TRUE" ];
    ```
    

依存関係はbuildInputsキーで管理します。
例えばパッケージにgtk依存を追加する場合は関数頭とbuildInputsにgtkを追加すればいいです。(meta省略)

{ stdenv, fetchurl, gtk }:

stdenv.mkDerivation rec {
  name = "hello-2.10";

  src = fetchurl {
    url = "mirror://gnu/hello/${name}.tar.gz";
    sha256 = "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i";
  };

  buildInputs = [ gtk ];

}

たまにソース以外にデータファイルを必要とするパッケージがあります。その場合ではletを利用し、そのデータファイル情報をmkDerivationのスコープにもっていき、該当フェーズで利用します。

fcitx-mozcパッケージからの例:

{ clangStdenv, fetchFromGitHub, fetchurl, fetchpatch, fetchsvn, gyp, which, ninja, 
  python, pkgconfig, protobuf, gtk, zinnia, qt4, libxcb, tegaki-zinnia-japanese,
  fcitx, gettext }:
let
  japanese_usage_dictionary = fetchsvn {
    url    = "http://japanese-usage-dictionary.googlecode.com/svn/trunk";
    rev    = "10";
    sha256 = "0pyrpz9c8nxccwpgyr36w314mi8h132cis8ijvlqmmhqxwsi30hm";
  };
  icons = fetchurl {
    url    = "http://download.fcitx-im.org/fcitx-mozc/fcitx-mozc-icon.tar.gz";
    sha256 = "10bdjn481jsh32vll7r756l392anz44h6207vjqwby3rplk31np1";
  };
in clangStdenv.mkDerivation rec {
  name    = "fcitx-mozc-${version}";
  version = "2.17.2313.102";

  src = fetchFromGitHub {
    owner  = "google";
    repo   = "mozc";
    rev    = "3306d3314499a54a4064b8b80bbc1bce3f6cfac4";
    sha256 = "0l7mjlnbm6i1ipni8pg9ym5bjg3rzkaxi9xwmsz2lddv348sqii2";
  };

  nativeBuildInputs = [ gyp which ninja python pkgconfig ];
  buildInputs = [ protobuf gtk zinnia qt4 libxcb fcitx gettext ];

  postUnpack = ''
    rmdir $sourceRoot/src/third_party/japanese_usage_dictionary/
    ln -s ${japanese_usage_dictionary} $sourceRoot/src/third_party/japanese_usage_dictionary
    tar -xzf ${icons} -C $sourceRoot
  '';

japanese_usage_dictionaryとiconsはsrcと別圧縮ファイルとなりますが、パッケージビルドには必要です。
srcを解凍した後に、postUnpackでjapanese_usage_dictionaryをビルドフォルダーにリンクし、アイコンあっすくファイルをビルドフォルダーに解凍します。

パッケージを作成する前にはパッケージがnixpkgsで存在しないのを確認しましょう。

作成には2つの方法があります

• ローカルnixpkgsクローンを利用: レポジトリの準備の手間がありますが、プールリクエストしやすいです
• 単独パッケージ: 簡単に作れますが、PRをする際にレポジトリのクローンの関すの頭の修正が必要となります

初心者に取って一番な単独パッケージの方法から紹介します。

利点としては

• 関数頭がシンプルで済む
• Nix expressionだけでパッケージをビルドできます

helloパッケージの単独バージョンを見ましょう

{ pkgs ? import <nixpkgs> {} }: 
with pkgs;

stdenv.mkDerivation rec {
  name = "hello-2.10";

  src = fetchurl {
    url = "mirror://gnu/hello/${name}.tar.gz";
    sha256 = "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i";
  };
}

※ 単独パッケージは外部ツールのの連携はないので、metaキーは必要内です。

このNix expressionをhello.nixに保存して、nix-build hello.nixを実行すれば、パッケージをビルドできます。
ビルドされた結果はnix-buildが実行されたフォルダーにresultと言ったNixストアパッケージへのリンクを作ります。
実行可能プログラムは./result/bin/以下に入っていますので、実行を試しましょう。

nixpkgsでのパッケージの書き方と比べて、関数頭しか変わらないです。
では分析しましょう:

{ pkgs ? import <nixpkgs> {} }: 

多少わかりにくいので、括弧をつけましょう

{ pkgs ? ((import <nixpkgs>) {}) }: 

この短い記述でいろいろをやっています。
まずは{ pkgs }:はpkgsを引数を利用する関数頭です（関数頭はセットと異なって:がついています）
関数頭で{ var ? "value" }:はvar引数に"value"デフォルト値を設定します、言い方を変えて、varが渡されていない場合にvarを"value"にします。
今回の例ではpkgs引数のデフォルトバリューをimport <nixpkgs> {}にします。

import <nixpkgs> {}に優先を表す括弧をつけると((import <nixpkgs>) {})になります。
importはNixのビルトイン関数であります、importでNix Expressionを文字通りにインポートできます。
<nixpkgs>は特別省略であり、NIX_PATH環境変数で定義されたnixpkgsを指します。

<nixpkgs>のパスは次のコマンドで確認できます:

# echo $NIX_PATH

でimport関数はパスをフォルダーを渡された時にdefault.nixを読み込みますので、NIX_PATHのdefault.nixをインポートします。

最後のパーツは((import <nixpkgs>) {})の{}です、インポートされるdefault.nixは関数であるために引数を渡さないと結果が帰ってこないです。
特別な引数を渡す必要は内ので、空セット{}を渡します。

説明が大分長くなりましたが、一言でまとめると{ pkgs ? import <nixpkgs> {} }:はpkgs引数にnixpkgsを読み込ませます。

次の行に出てくるwith pkgs;はpkgsのキーを次のexpressionのスコープに共有します。
簡単にいいますとstdenvとfetchurlがpkgsに含まれているので、withのおかげでpkgs.stdenv.mkDerivationやpkgs.fetchurlを書く必要がなく、pkgsを省略できます。

単独パッケージの作成が終わったら、nixpkgsに登録する事はできます。

まずはローカルにnixpkgsのクローンを作ります:

# git clone https://github.com/NixOS/nixpkgs.git
# cd nixpkgs

nixpkgsにはNixで利用すべてのパッケージとNixOS関連のソースコードが管理されています。

トップレベルフォルダーは

• doc: nixpkgsのドキュメンテーション
• lib: Nix言語のライブラリ関数
• maintainers: メンテナ用のスクリプト等
• nixos: NixOS関連コード
• pkgs: パッケージ

パッケージはpkgフォルダーの下に入ります、pkg以下はカテゴリ毎にフォルダーがあります。
パッケージをどのフォルダーに置くにルールが曖昧で、一番カンタンのは似たパッケージを探し、そのパッケージと同じカテゴリに置けば良いです。

例としては先程の単独パッケージを利用します。
helloはすでにnixpkgsに存在しますので、パッケージ名をmy-helloに変更します。

my-hello.nix:

{ pkgs ? import <nixpkgs> {} }: 
with pkgs;

stdenv.mkDerivation rec {
  name = "my-hello-2.10";

  src = fetchurl {
    url = "mirror://gnu/hello/${name}.tar.gz";
    sha256 = "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i";
  };
}

プールリクエストのためにパッケージ専用ブランチを作りましょう:

# git checkout -b pkg/my-hello

helloはpkgs/applications/misc/の下にありますので、my-helloも同様にpkgs/applications/misc/に置きましょう。 まずはフォルダーを作ります。

# mkdir pkgs/applications/misc/my-hello/

nixpkgsではパッケージのNix expression名をdefault.nixにする決まりがあります。

# cp my-hello.nix pkgs/applications/misc/my-hello/default.nix

次のステップはmy-helloをパッケージリストに登録します、nixpkgsのパッケージリストはpkgs/top-level/all-packages.nixにあります。

パッケージリストは瀬戸であり、書くパッケージはキーであります。 書き方は:

  キー = callPackage パス 引数;

callPackageはimportの様にNix expressionをインポートし、他のパッケージを読み込んだNix expressionのスコープに共有します。

helloパッケージの記述を確認しましょう

  hello = callPackage ../applications/misc/hello { };

my-helloのパッケージ定義

  my-hello = callPackage ../applications/misc/my-hello { };

残りはmy-helloのNix expressionの関数頭の修正とmetaキーの追加。

単独パッケージの関数頭は

{ pkgs ? import <nixpkgs> {} }: 
with pkgs;

callPackageのおかげでpkgsのすべてのキーは関数頭で利用できます。
そのためNix Expressionに利用するパッケージを関数頭に入れればいいです。
my-helloはstdenvとfetchurlを利用しますので、次のように関数頭を修正します。

{ stdenv, fetchurl }: 

※ with pkgs;は不要となりますので、行ごとを削除します。

後はmkDerivationのmetaを追加すれば完成します。

helloパッケージのmetaセットを確認しましょう

  meta = {
    # パッケージの概要、一行内で「.」をつけないです
    description = "A program that produces a familiar, friendly greeting";
    # パッケージの紹介
    longDescription = ''
      GNU Hello is a program that prints "Hello, world!" when you run it.
      It is fully customizable.
    '';
    # パッケージのホームページ
    homepage = http://www.gnu.org/software/hello/manual/;
    # パッケージのライセンス
    license = stdenv.lib.licenses.gpl3Plus;
    # パッケージのメンテナ
    maintainers = [ stdenv.lib.maintainers.eelco ];
    # パッケージの対応プラットフォーム
    platforms = stdenv.lib.platforms.all;
  };

licenseに設定するはstdenv.lib.licensesセットのキーとなります、ライセンス一覧はlib/licenses.nixで確認できます。

maintainersはパッケージメンテナのリストとなります、自分をメンテナに設定する場合はlib/maintainers.nixに自分の情報を追加する必要があります。

platformsはパッケージが対応するプラットフォームになります、プラットフォーム一覧はlib/platforms.nixで確認できます。

パッケージが完成しましたら、nix-buildコマンドでビルドできます。 nixpkgsのルートフォルダーに

# nix-build -A my-hello