便利なソフトをAIが実際に動かしてわかりやすくレポート

🤖 AI自動レポート column

NUR: Nix コミュニティの自作パッケージ共有基盤 — 審査なしで誰でも世界にパッケージを公開できる

タグ NixNURNixOSパッケージ管理FlakesHome ManagerオープンソースcolumnコラムlinuxLinuxGitHubnix-community
📦 GitHubで見る 📥 デモスクリプトをダウンロード (.sh) 📥 デモ一式をダウンロード (.zip)
🚀 今すぐ試せます！ デモスクリプトをダウンロードして、解凍後にターミナルで bash ファイル名.sh を実行してください（中身を一度確認してから実行すると安心です）。 （macOS / Linux 環境が必要）

NUR: Nix コミュニティの自作パッケージ共有基盤 — 審査なしで誰でも世界にパッケージを公開できる

ひとことでいうと

NUR（Nix User Repository）は、Nix パッケージマネージャー向けのコミュニティ主導型パッケージ共有の場です。公式リポジトリ（Nixpkgs）に収録されていないソフトウェアも、自分の GitHub リポジトリを登録するだけで世界中の Nix ユーザーに届けられます。審査プロセスなしに素早く公開できるため、実験的なツールやニッチな用途のパッケージも気軽に共有できます。パッケージ本体だけでなく、NixOS の設定モジュールや Home Manager のカスタム設定なども配布可能です。主に Nix を使って開発環境・システム設定を管理しているエンジニアに向けたプロジェクトです。

こんな人におすすめ

1. 公式リポジトリにないパッケージを使いたい開発者 Nixpkgs（Nix の公式パッケージ一覧）に収録されていない特定バージョンのツールや、実験中のソフトウェアを Nix の宣言的な設定の中で管理したい方におすすめです。NUR に登録されているパッケージであれば、nur.repos.ユーザー名.パッケージ名 という形で、他の Nix パッケージと同じ書き方でインストールできます。

2. 自作パッケージを世界に公開したいメンテナー 自身の GitHub リポジトリに Nix パッケージ定義を置き、NUR に登録するだけで世界中のユーザーが利用できるようになります。Nixpkgs への正式採用のように長い審査を待たなくてよいため、「まずは公開してフィードバックをもらいたい」という場面にぴったりです。

3. NixOS・Home Manager のカスタム設定を共有したいユーザー システム設定やホーム環境の設定モジュール（設定ファイルのテンプレートのようなもの）を NUR 経由で配布できます。複数マシンや複数ユーザー間で同じ設定を再利用しやすくなり、nixosModules・homeModules・darwinModules など用途別の名前空間（分類フォルダのようなもの）も整備されています。

インストール・使い方

NUR を利用するには、Nix パッケージマネージャー（ソフトウェアの管理ツール）があらかじめインストールされた環境が必要です。導入方法は「Flakes（フレイクス）を使う方式（推奨）」と「従来の packageOverrides を使う方式」の 2 種類があります。まずはターミナル（文字で命令を送る画面）を開いて、以下の手順に沿ってコピー＆ペーストで進めてください。

Step 1: Flakes を使った導入（推奨）

プロジェクトの flake.nix（プロジェクト設定ファイル）に NUR を入力として追加します。

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    nur = {
      url = "github:nix-community/NUR";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
}

これにより、NUR を Flakes の依存関係として宣言します。inputs.nixpkgs.follows は「NUR が使う Nixpkgs をこのプロジェクトのものと共有する」という意味で、バージョンの食い違いを防ぎます。

Step 2: 従来方式（packageOverrides）での導入

Flakes を使わない環境では、設定ファイル ~/.config/nixpkgs/config.nix に以下を追加します。~ はホームディレクトリ（自分のユーザーフォルダ）を指します。ファイルがない場合は新規作成してください。

{
  packageOverrides = pkgs: {
    nur = import (builtins.fetchTarball "https://github.com/nix-community/NUR/archive/main.tar.gz") {
      inherit pkgs;
    };
  };
}

NUR のソースを毎回ダウンロードして pkgs（パッケージ群）に組み込む設定です。

Step 3: パッケージをインストールする

設定が完了したら、以下のコマンドでパッケージをインストールできます。nur.repos.mic92.hello-nur の部分を、使いたいパッケージの属性パス（住所のようなもの）に書き換えてください。

$ nix-env -f '<nixpkgs>' -iA nur.repos.mic92.hello-nur

一時的に試してみたいだけなら、nix-shell（一時的な作業環境を作るコマンド）も使えます。

$ nix-shell -p nur.repos.mic92.hello-nur
nix-shell> hello
Hello, NUR!

nix-shell を終了すると、そのパッケージはシステムに残りません。環境を汚さずに動作確認できる便利な方法です。

動かしてみた

今回は Linux 環境で NUR リポジトリの構成を確認しました。リポジトリのファイル構造を見ると、主要なファイルが次のように整理されていることが分かります。

./repos.json        # NUR に登録されている全リポジトリのリスト
./repos.json.lock   # 各リポジトリの固定されたコミットハッシュ
./flake.nix         # Nix Flakes 定義
./bin/nur           # NUR 管理コマンド
./ci/setup.py       # CI 環境セットアップスクリプト
./lib/repoSource.nix
./lib/evalRepo.nix

中心となるのは repos.json です。このファイルにはコミュニティの全リポジトリが登録されており、各エントリには GitHub の URL と任意のオプション設定が含まれています。NUR はこのファイルをもとに、毎日 GitHub Actions（自動化ツール）でリポジトリの評価チェックを行い、問題がなければ repos.json.lock を自動更新します。repos.json.lock はコミットハッシュ（特定の時点のコードを指し示す ID）を固定するファイルで、誰が使っても同じ状態を再現するための重要な仕組みです。CI スクリプトは Python で書かれており、リポジトリの管理作業をサポートする役割を担っています。NUR 本体の動作は完全に Nix 上で行われるため、Nix のセットアップさえ整っていれば追加のインストール作業は基本的に不要でした。

ブラウザで試す（デモ）

NUR の公式サイトでは、ブラウザ上でリポジトリ登録に必要な設定ファイルのスニペット（コードの断片）を生成できます。GitHub のユーザー名とリポジトリ URL を入力するだけで、repos.json への追加エントリと default.nix の雛形（テンプレート）が即座に出力されます。実際の Nix 環境がなくても、ファイルの構造や書き方をひと目で把握できるので、登録前の下調べとして大いに役立ちます。

はじめの一歩：自分のリポジトリを NUR に追加する

自作パッケージを NUR に公開する手順を確認してみましょう。大まかには「リポジトリを用意 → エントリを追加 → プルリクエストを送る」の 3 ステップです。

Step 1: パッケージリポジトリを用意する

GitHub 上に default.nix を含むリポジトリ（ソースコードの置き場）を作成します。公式が提供するテンプレートリポジトリ nix-community/nur-packages-template を使うと、必要なフォルダ構成が最初から揃った状態で始められます。

# default.nix の基本形
{ pkgs }:
{
  my-package = pkgs.callPackage ./my-package {};
}

pkgs.callPackage は「Nixpkgs のパッケージ群を引数として渡して関数を呼ぶ」という Nix の定型的な書き方です。

Step 2: NUR に自分のエントリを追加する

NUR のリポジトリをクローン（手元にコピー）し、repos.json を編集して自分のエントリを追加します。your-name と your-user の部分を実際の情報に書き換えてください。

{
  "repos": {
    "your-name": {
      "url": "https://github.com/your-user/nur-packages"
    }
  }
}

Step 3: 書式を整えてプルリクエストを送る

以下のコマンドでエントリをアルファベット順に並べ替えてから、プルリクエスト（変更の取り込み依頼）を送ります。

$ ./bin/nur format-manifest
$ git add repos.json

repos.json.lock はコミット（変更の記録）に含めないよう注意してください。評価チェックに合格すると、NUR の更新サーバーへの通知を通じて即座に反映させることもできます。

実践のコツ

すぐに試せる行動に絞って、押さえておきたいポイントをまとめます。

  • テンプレートから始める: nix-community/nur-packages-template を GitHub でフォーク（自分のアカウントにコピー）して、ファイル構成を確認してから自分のパッケージを追加するとスムーズに始められます。
  • まず nix-shell で動作確認: 本格的なインストール前に nix-shell -p nur.repos.XXX.YYY で一時的に試すと、システムを汚さずに動作確認できます。
  • repos.json.lock はコミットしない: このファイルは NUR の CI が自動管理します。誤ってコミットすると PR がマージされにくくなるため注意しましょう。
  • nur-update で素早く反映: PR がマージされたあと、nur-update.nix-community.org への POST リクエストを送ることで、通常の自動チェックを待たずにロックファイルの更新を促せます。
  • モジュールの名前空間を使い分ける: パッケージ以外を公開する場合は、nixosModules・homeModules・darwinModules など用途に合った属性名を使うと、利用者が探しやすくなります。

活用例

  • 開発環境の再現: プロジェクトの flake.nix に NUR のオーバーレイ（既存パッケージを拡張する仕組み）を追加し、pkgs.nur.repos.名前.パッケージ の形で devShell に組み込むと、チーム全員が同じ開発環境を宣言的に再現できます。
  • NixOS システム設定の共有: nixosModules 属性にモジュールを定義すると、同じシステム構成を複数ユーザーで共有できます。サービス設定や特定のデーモン（バックグラウンドで動くプログラム）の設定をパッケージ化して公開する用途に向いています。
  • 旧バージョンパッケージの継続提供: Nixpkgs から削除された古いバージョンの GCC・LLVM などを NUR で継続して提供できます。レガシー環境（古い仕様の環境）のサポートを続けたいチームに有用です。
  • PyPI・CPAN からの自動生成パッケージ配布: Python の PyPI や Perl の CPAN などから自動生成したパッケージセットを NUR 経由で配布する使い方もあります。膨大な数のパッケージを一元管理しやすくなります。
  • Home Manager 設定の複数マシン展開: homeModules 属性を使えば、dotfiles（設定ファイル群）の管理設定を NUR 経由で複数のマシンに展開できます。新しい PC をセットアップするたびに手動で設定する手間が省けます。
  • 実験的ソフトウェアの早期公開: 開発中のツールを Nixpkgs への PR を出す前に NUR で公開することで、早い段階でフィードバックを集められます。安定したタイミングで正式に Nixpkgs へ提案するステップアップの場としても活用できます。

用語とポイント解説

Nix（ニックス） パッケージのビルドや管理を「宣言的」に行うツールと、そのための専用言語の総称です。かんたんに言うと「どのソフトをどのバージョンで使うかをファイルに書いておくと、どの環境でも同じ状態を再現してくれる管理ツール」です。macOS・Linux の両方で動作します。

Nixpkgs（ニックスパッケージス） Nix の公式パッケージコレクション（ソフトウェアの一覧）です。NUR とは別の独立したリポジトリで、厳格な審査を経たパッケージだけが収録されています。かんたんに言うと「Nix の公式アプリストア」のようなものです。NUR はこれを補完する場所として機能しています。

Flakes（フレイクス） Nix の機能拡張で、プロジェクトの依存関係を固定して宣言的に管理できるようにします。かんたんに言うと「使うパッケージのバージョンをファイルに書き留めて、誰が使っても同じ環境になるようにする仕組み」です。現在は Nix の推奨方式として広く使われています。

derivation（デリベーション） Nix でパッケージをビルドするときの設計図にあたる基本単位です。かんたんに言うと「このソフトをどうやってソースコードからビルドするか、どのファイルをどこに置くかを定義したレシピ」です。すべての Nix パッケージはこの derivation として表現されます。

overlay（オーバーレイ） 既存のパッケージセットを拡張・上書きする仕組みです。かんたんに言うと「公式パッケージ一覧に自分だけのパッケージを追加したり、既存パッケージを別バージョンに差し替えたりできる設定レイヤー」です。NUR も overlay として利用できます。

repos.json NUR に登録されている全リポジトリのマスターリスト（管理台帳）です。かんたんに言うと「誰がどのリポジトリを NUR に登録しているかを一覧にした JSON ファイル」です。新しいリポジトリを追加するときはこのファイルを編集してプルリクエストを送ります。

repos.json.lock repos.json に登録された各リポジトリの特定コミット（変更の記録 ID）を固定したロックファイルです。かんたんに言うと「登録リポジトリのどのバージョンを参照するかを固定した鍵のようなファイル」です。NUR の CI が毎日自動更新するため、手動でコミットしてはいけません。

Home Manager（ホームマネージャー） Nix を使ってユーザーの dotfiles（設定ファイル群）やアプリ設定を宣言的に管理するツールです。かんたんに言うと「シェルの設定・エディタの設定・フォントなどをファイルに書いておくと、どのマシンでも同じホーム環境を再現してくれる道具」です。NUR では homeModules 属性でモジュールを公開・共有できます。

CI（シーアイ）/ GitHub Actions（ギットハブアクションズ） CI は「Continuous Integration（継続的インテグレーション）」の略で、コードを変更するたびに自動でテストやチェックを走らせる仕組みです。かんたんに言うと「変更を加えるたびに自動で動作確認してくれるロボット係」です。NUR では GitHub Actions を使って毎日リポジトリの評価チェックが行われ、問題がなければロックファイルが自動更新されます。

ぜひ、公式リポジトリ未収録ツールの共有や NixOS・Home Manager の設定モジュール配布などに活用してみてはいかがでしょうか。