Nimble

Nimのパッケージマネージャ
Nimのパッケージ管理を簡単に行うためのツール。

カテゴリー：パッケージマネージャ
対応Nimバージョン：使っている Nim 本体のバージョンに準拠
公式レポジトリ：https://nim-lang.github.io/nimble/




Nimbleとは？


概要

Nimbleは、Nimの世界で「ライブラリを探す」「必要な依存関係を入れる」「自分のプロジェクトを雛形から作る」「ビルドやテストを回す」「自作パッケージを公開する」といった作業を一括して扱うための標準ツールである。
Nimのコードを書くこと自体はコンパイラ nim が担当するが、周辺の実務、特に依存関係と配布の管理はNimbleが担当する。
したがって、初心者にとってのNimbleは、単なる追加ツールではなく、Nim開発を現実的に回すための入口そのものだと考えてよい。

Nimbleは既存パッケージのインストールだけでなく、新しいNimbleパッケージの作成も支援する。nimble init を使えば、.nimble ファイル、src ディレクトリ、tests ディレクトリを含む推奨構成を自動で作れるため、初心者でも「何をどこに置けばよいか」で迷いにくい。
さらに、.nimble ファイルは単なる設定ファイルではなく、依存関係、ビルド対象、インストール対象、カスタムタスクなどを記述できる中核ファイルになっている。

また、Nimbleは公式パッケージ一覧を扱うが、一覧に載っているパッケージが品質保証されているわけではない。
公式の packages リポジトリでも、掲載パッケージは審査済みではなく、品質や成熟度を保証しないと明記されている。
つまり、Nimbleは便利な流通経路を提供するが、導入するパッケージの信頼性判断までは利用者側の責任である。
ここは初心者ほど見落としやすいので、最初に押さえておくべき点である。

特徴

Nimbleの第一の強みは、Nimに標準で寄り添っている点である。
Nim本体に同梱されているため、最新のNimを入れていれば最初から使えることが多く、別のパッケージマネージャを最初に覚える必要がない。
さらに、既存パッケージの導入では、名前指定だけでなくGitやMercurialのURL、さらにはサブディレクトリ付きURLまで扱えるため、公式一覧にないパッケージでも直接導入できる。

第二の強みは、依存関係の宣言と開発フローが一つの仕組みにまとまっている点である。
.nimble ファイルには requires による依存関係、srcDir や bin による構成情報、task による独自コマンド、before などのフックまで書ける。
しかも .nimble はNimScriptで解釈されるため、条件分岐でOSごとに依存関係を変えるといった柔軟な記述もできる。
このため、単なる「入れる道具」ではなく、プロジェクト運営ルールをまとめる場所として使える。

第三の強みは、近年のNimbleがNimのバージョン管理やロックファイルにも踏み込んでいる点である。
公式ガイドでは、Nimbleはプロジェクトの requires "nim >= ..." を見て、互換Nimがなければ取得し、nimble.lock で正確な依存バージョンを固定できるとしている。
これにより、個人開発では「昨日は動いたのに今日は壊れた」を減らしやすく、複数人開発では全員が同じ依存関係を再現しやすい。
ここは、ただのインストーラと比べたときの大きな違いである。

さらに、Nimコンパイラ単体とNimbleの役割分担が明確なのも実務上は重要である。Nimコンパイラは .nimble ファイル自体を読まず、Nimbleが解決した依存パスを渡されて初めて、正確なバージョンのライブラリを使ってビルドできる。
つまり、普段の素早い試し打ちは nim でもよいが、配布や公開前の確認は nimble build や nimble check で行う方が安全である。

使いどころ

最も基本的な使いどころは、外部ライブラリを導入するときである。
たとえばWeb開発でJesterのようなフレームワークを使いたい、JSONや非同期処理の補助ライブラリを足したい、というときにNimbleで検索・導入を行う。
Nimの標準ライブラリだけでは足りない機能を安全に組み込む入り口がNimbleだと考えればよい。

次に重要なのは、新しいプロジェクトを始めるときである。
初心者は、ソースをどこに置くか、テストはどう分けるか、パッケージ名とモジュール名をどう揃えるかでつまずきやすい。
nimble init を使えば、そうした初期設計を推奨形で始められるため、後で構成が崩れて困る可能性が下がる。
特に srcDir = "src" を含む基本構成を自動で作ってくれる点は、最初の混乱をかなり減らしてくれる。

三つ目は、チーム開発や将来の自分のための再現性確保である。
依存関係が複数あるプロジェクトでは、誰かの環境では動くが別の環境では動かない、という問題が起きやすい。
Nimbleは nimble.lock で依存の正確な版を固定し、nimble setup や nimble sync でそれを各開発環境に揃える流れを持っている。
小規模開発でも、この再現性は思っている以上に効く。

四つ目は、依存ライブラリそのものを追いかけたい場合である。
たとえば、あるパッケージの最新版で不具合が直っているかを試したい、自分で依存先を一時的に修正して検証したい、というときに nimble develop が役に立つ。
これは単なるインストールではなく、依存先を開発モードで手元に展開し、ロックファイルと同期しながら扱うための仕組みである。
初心者には少し上級だが、ライブラリ依存の深い開発に入るなら避けて通れない。

最後に、NimbleはNim本体やツール類の導入にも使える。
公式ガイドでは、NimbleでNimをグローバルに導入でき、nimlangserver などの関連ツールも入れられるとしている。
つまりNimbleは、ライブラリ導入だけでなく、Nim開発環境全体の整備役でもある。

使い方

まず、Nimbleが使える状態かを確認する。
Nimbleは通常Nimに同梱されるため、多くの環境ではNimを入れた時点で使える。
とはいえ、実際にどの版が入っているかは環境ごとに異なるため、最初に nimble -v で確認しておくべきである。
公式リポジトリでも、ガイドは最新コミット向けであり、実際のNimリリースに入っているNimbleには差がありうるので nimble -v を見よと案内している。

既存ライブラリを探して入れるだけなら、流れはかなり単純である。
まず nimble search で候補を探し、見つかったら nimble install で導入する。install は依存関係も追って入れてくれる。
なお、Nimbleは通常「最新のタグ付き版」を最新版とみなし、タグがない場合はリポジトリの最新コミットを導入する。
この挙動を理解していないと、「思ったより新しい版が入らない」「逆に最新コミットが入った」と感じやすい。 

                    
# 例：Jesterを入れる
nimble search jester
nimble install jester
nimble list -i
nimble deps

新規プロジェクトを始めるなら、空ディレクトリで nimble init を実行するのが基本である。
ウィザードではパッケージ種別、版、説明、ライセンス、最低対応Nim版などを聞かれ、その結果が .nimble ファイルに保存される。
作成直後の構成は、概ね「プロジェクト直下に .nimble、src、tests」という形になる。
初心者が手で作るより、まずはこの形を受け入れた方が事故が少ない。 

                    
mkdir helloapp
cd helloapp
nimble init

作られる構成の基本形は次のようなイメージである。 

                    
helloapp/
├─ helloapp.nimble
├─ src/
│  └─ helloapp.nim
└─ tests/
   └─ test1.nim

.nimble ファイルでは、少なくともパッケージの説明と依存関係を把握しておきたい。
たとえば requires "nim >= 2.0.0" のように最低Nim版を宣言し、必要な外部ライブラリも requires で並べる。
ソースを src に置くなら srcDir = "src" が必要で、nimble init はそこまで自動で面倒を見てくれる。
複数OSに対応したいなら、NimScriptの when defined(...) を使って依存関係を分岐させることもできる。 

                    
例：helloapp.nimble

version = "0.1.0"
author = "yourname"
description = "sample app"
license = "MIT"
srcDir = "src"

requires "nim >= 2.0.0"
requires "jester >= 0.6.0"

ビルドと実行では、目的によってコマンドを使い分ける。
nimble build はパッケージ全体を既定設定でビルドし、nimble test は tests ディレクトリ内のテストをまとめて走らせ、nimble run は .nimble の bin に定義された実行バイナリをビルドして起動する。
nimble c 系は個別モジュールのコンパイル確認向きであり、nimble check はパッケージ構成や整合性の検証に使う。
公開前に nimble check を通す癖はつけておいた方がよい。 

                    
nimble build
nimble test
nimble run
nimble check
nimble dump --json

独自の作業手順をコマンド化したいなら、.nimble に task を書く。Nimbleでは .nimble がNimScriptとして動くため、簡単な自動化をそのまま埋め込める。
たとえばテスト前の準備や、ドキュメント生成、複数コマンドのまとめ打ちなどをnimble docs や nimble ci のような名前で定義できる。
さらに before フックを使えば、特定コマンドの前処理も書ける。これは小さな自動化だが、積み重なるとかなり効く。 

                    
task hello, "挨拶を出すタスク":
  echo "Hello from Nimble"

before hello:
  echo "これから hello を実行する"
                    
                
                    
nimble hello
nimble tasks

依存関係をチームで揃えたい場合は、nimble setup と nimble lock を覚える。
nimble setup は依存パスを書いた nimble.paths を作り、それを config.nims に取り込む。
nimble.lock は依存先の正確な版や取得元を固定するファイルであり、こちらはコミット対象になる。
逆に nimble.paths や nimble.develop はユーザー環境依存なのでコミットしてはいけない。
ここを混同すると、リポジトリがすぐ汚れる。 

                    
nimble setup
nimble lock
nimble check

依存ライブラリを手元で改造しながら試すときは nimble develop を使う。
これは依存先を開発モードでクローンし、nimble.develop で参照させる仕組みである。
たとえばライブラリの最新版を先に試したい、あるいは依存先を一時修正したい場合に有効だ。
作業後にロックファイルと状態がずれたら nimble sync で同期する。
複数人開発では、この運用を理解していないと「自分の環境だけ動く」状態を作りやすい。 

                    
nimble develop itertools
nimble check
nimble sync

最後に、Nimコンパイラ nim とNimbleを混同しないことが大切である。
nim はソースをコンパイルする道具であり、依存解決の中心はNimbleが担う。
したがって、ちょっとした検証なら nim c -r でもよいが、依存関係が絡む本番のパッケージ確認では nimble build や nimble check を優先した方が安全である。
初心者のうちは「動いたから正しい」と思いがちだが、公開可能な状態かどうかは別問題である。

注意点

最初に気をつけるべきなのは、Nimble自体の実行環境である。
公式ガイドでは、NimbleはGitやMercurialに依存し、特にGitは少なくとも 2.22 以上を推奨している。
つまり、Nimbleコマンドがあるだけでは不十分で、裏側で取得に使うVCSツールが整っていないとインストールで失敗する。
パッケージ取得に失敗したら、まずGitがPATHにあるかを疑うべきである。

次に多いのはPATHまわりの問題である。Nimbleが導入した実行ファイルは通常 ~/.nimble/bin に置かれるため、ここがPATHに入っていないと、インストール済みツールをコマンドとして呼べない。
公式の導入手順でも、nimble install nimble を使う場合は ~/.nimble/bin をPATHに入れておく必要があるとしている。
導入したのに動かないときは、かなりの確率でここである。

構成エラーも初心者によく出る。
代表例として、nimble check 時に「パッケージ名とソース階層の構造が合っていない」と警告・失敗するケースがある。
たとえば foobar.nim を、本来のパッケージ名と違うディレクトリに置くと検証で弾かれる。
対処法は、推奨どおりパッケージ名に沿ったディレクトリへ置き直すか、意図的に含めないものなら .nimble に skipDirs などを書くことだ。
手で適当に並べるより、nimble init が作る形を守る方が安全である。

SSL関連のエラーも公式トラブルシューティングに載っている。
SSL support is not available. Cannot connect over SSL. [HttpRequestError] の場合は src/nimble.nim.cfg に -d:ssl を加えて再インストールする対処が示されている。
macOSで sslv3 alert handshake failure が出る場合は、OpenSSLライブラリの場所を DYLD_LIBRARY_PATH に通す必要があると案内されている。
ネットワークエラーに見えても、実際にはローカルのSSL設定不足であることがある。

少し古い環境では、.nimble 実行中に Error: ambiguous identifier: 'version' --use nimscriptapi.version or system.version が出ることがある。
公式には、少なくとも Nim 0.16.0 以上、できればより新しい版を使うよう案内されている。
また、Error: cannot open '/home/user/.nimble/lib/system.nim' のように標準ライブラリが見つからない場合は、Nimble側の不具合として報告対象でありつつ、暫定回避として NIM_LIB_PREFIX を設定できるとされている。
よく分からないエラーでも、まずはバージョン確認と環境変数確認を行うべきである。

依存関係の一覧が古いこともある。
Nimbleはパッケージ一覧を自動で常に更新するわけではないため、検索や導入がうまくいかない場合は nimble refresh を試す必要がある。
これは地味だが、初心者が「パッケージが存在しない」と誤解しやすい原因の一つである。

最後に、最近のガイドと自分のローカル環境の差にも注意したい。
公式リポジトリは、ガイドが最新コミット向けであり、Nimリリースに入っているNimbleはその内容をまだ含まないことがあると明記している。
つまり、記事や公式ガイドどおりに打っても自分の環境では未対応、ということが起こりうる。
その場合はまず nimble -v を見て、今触っているNimbleの版を基準に判断すべきである。ここを見ないまま悩むのは非効率である。

型・関数・API

Nimbleは、通常の import nimble で関数を呼ぶライブラリというより、実務上は「コマンド群」と「.nimble ファイルの宣言」が利用者向けAPIである。
したがって、初心者が覚えるべき対象もその二つが中心になる。
加えて、nimble init のウィザードではパッケージ種別として library / binary / hybrid を選ぶため、これを型に近い分類として理解しておくとよい。

  1. パッケージ種別
    • library: 他のNimコードから import して使われるライブラリ中心のパッケージ種別。
    • binary：エンドユーザーが実行するバイナリを生成するパッケージ種別。
    • hybrid：ライブラリとしてもバイナリとしても扱える複合型のパッケージ種別。
  2. 主要コマンドAPI
    • nimble install：既存パッケージを導入する基本コマンドで、依存関係も一緒に解決する。
    • nimble install <url>：公式一覧にないパッケージでも、GitやMercurialのURLから直接導入できる。
    • nimble install --depsOnly：カレントプロジェクトの依存関係だけをまとめて入れる。
    • nimble search：名前やタグの一部から利用可能パッケージを探す。
    • nimble list：利用可能なパッケージ一覧、または -i でローカル導入済み一覧を確認する。
    • nimble refresh：公式パッケージ一覧を更新する。検索結果が古いときに使う。
    • nimble deps：現在のパッケージの依存ツリーを表示する。
    • nimble uninstall：導入済みパッケージを削除する。依存関係がある場合は注意が必要である。
    • nimble init：新しいNimbleプロジェクトの雛形を作る。初心者の出発点である。
    • nimble build：パッケージ全体を既定設定でビルドする。公開前確認でも使う。
    • nimble run：.nimble の bin に定義された実行対象をビルドして起動する。
    • nimble test：tests 配下のテスト群をまとめて実行する。
    • nimble c / compile / js / cc / cpp：個別モジュールのコンパイル確認やバックエンド切替に使う。
    • nimble check：パッケージ構造や依存状態の妥当性を検証する。
    • nimble dump：メタデータをINIまたはJSON形式で出力する。外部ツール連携向きである。
    • nimble publish：自作パッケージを公式一覧へ登録する補助を行う。
    • nimble tasks：.nimble に定義したカスタムタスク一覧を確認する。
    • nimble setup：nimble.paths と config.nims を整備し、依存パスをコンパイラへ渡せる状態にする。
    • nimble lock：nimble.lock を生成・更新し、依存版を固定する。
    • nimble develop：依存パッケージを開発モードにし、手元で改造・検証しやすくする。
    • nimble sync：開発モード依存とロックファイルの内容を同期する。
  3. .nimble ファイルの主要宣言
    • version：パッケージ版を表す。公開前に更新し、タグ付けと対応させる。
    • author：作者名を記述する。
    • description：パッケージの説明文を書く。検索時の判断材料にもなる。
    • license：ライセンス名を記述する。公開物では特に重要である。
    • srcDir：ソースが入るディレクトリを指定する。src 構成ではほぼ必須である。
    • binDir：nimble build の出力先ディレクトリを指定する。
    • bin：ビルド対象の実行ファイル名を列挙する。バイナリパッケージ化の核である。
    • namedBin：実行ファイル名を別名付きで定義する。インストール時の名前制御に使える。
    • backend：c、cpp、js などのビルドバックエンドを指定する。
    • paths：追加の探索パスをNimコンパイラへ渡す。
    • entryPoints：nimlangserver がプロジェクト入口として見るファイルを指定する。
    • requires：依存パッケージやNimの必要バージョンを宣言する最重要項目である。
    • skipDirs / skipFiles / skipExt：インストール時に除外したい対象を指定する。
    • installDirs / installFiles / installExt：逆に、インストール対象を限定したいときに使う。
    • task：Nimble独自コマンドを定義する。プロジェクト自動化の中心である。
    • before：コマンド実行前フックを定義する。前処理の自動化に向く。
    • feature "dev" / dev:：開発時だけ必要な依存関係をまとめるための機能である。

参考文献

Nimbleは更新が続いているため、参照先はまず公式ガイドと公式リポジトリを優先するべきである。
特に使い方、.nimble 記法、developワークフロー、トラブル対応は公式文書を見た方が早い。

トップへ戻る


お問い合わせ