Bazel のモジュール は、複数のバージョンを持つことができる Bazel プロジェクトです。各バージョンは、依存する他のモジュールに関するメタデータを公開します。これは 、Maven の アーティファクト、npm のパッケージ、Go のモジュール、Cargo のクレートなど、他の依存関係管理システムの概念に似ています。
モジュールには、リポジトリのルートに MODULE.bazel ファイルが必要です。このファイルはモジュールのマニフェストであり、名前、バージョン、直接依存関係のリストなどの情報を宣言します。基本的な例を次に示します。
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
`
MODULE.bazel` ファイルで使用できるディレクティブの完全なリストをご覧ください。
モジュールの解決を行うため、Bazel はまずルート モジュールの
MODULE.bazel ファイルを読み取り、依存関係グラフ全体が検出されるまで、依存関係の
MODULE.bazel ファイルを Bazel レジストリ に繰り返しリクエストします。
デフォルトでは、Bazel は使用する各モジュールの 1 つのバージョンを選択します 。Bazel は各モジュールをリポジトリで表し、レジストリに再度問い合わせて、各リポジトリの定義方法を確認します。
バージョン形式
Bazel には多様なエコシステムがあり、プロジェクトではさまざまなバージョニング スキームが使用されています。圧倒的に人気があるのは SemVer ですが、Abseil など、日付ベースのバージョン（20210324.2 など）を使用するプロジェクトもあります。
このため、Bazel は SemVer 仕様のより緩いバージョンを採用しています。違いは次のとおりです。
- SemVer では、バージョンの「リリース」部分は
MAJOR.MINOR.PATCHの 3 つのセグメントで構成する必要があります。Bazel では、この要件が緩和され、任意の数のセグメントを使用できます。 - SemVer では、「リリース」部分の各セグメントは数字のみで構成する必要があります。 Bazel では、文字も使用できるようになり、比較セマンティクスは「プレリリース」部分の「識別子」と一致します。
- また、メジャー バージョン、マイナー バージョン、パッチ バージョンのセマンティクスは強制されません。ただし、下位互換性の表記方法については、 互換性レベルをご覧ください。
有効な SemVer バージョンは、有効な Bazel モジュール バージョンです。また、2 つの
SemVer バージョン a と b は、Bazel モジュール バージョンとして比較した場合と同じ場合にのみ a < b と比較されます。
モジュールのバージョニングの詳細については、よくある質問MODULE.bazel
をご覧ください。
バージョンの選択
バージョニングされた依存関係管理の分野では、ダイヤモンド依存関係の問題がよく知られています。次のような依存関係グラフがあるとします。
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
どのバージョンの D を使用する必要がありますか？この問題を解決するため、Bazel は
最小バージョン選択
（MVS）アルゴリズムを Go モジュール システムで導入された使用します。MVS
は、モジュールの新しいバージョンはすべて下位互換性があることを前提として、依存関係（この例では D 1.1）で指定された最も新しいバージョンを選択します。`D 1.1` は要件を満たすことができる最も古いバージョンであるため、「最小」と呼ばれます。
`D 1.2` 以降が存在する場合でも、選択されません。MVS を使用すると、
忠実度が高く再現可能なバージョンの選択プロセスが作成されます。
Yanked バージョン
レジストリは、回避する必要があるバージョン（セキュリティの脆弱性など）を yanked として宣言できます。 Bazel
は、モジュールの yanked バージョンを選択するとエラーをスローします。このエラーを修正するには、新しい
yanked でないバージョンにアップグレードするか、
--allow_yanked_versions
フラグを使用して yanked バージョンを明示的に許可します。
互換性レベル
Go では、モジュールの下位互換性のないバージョンは別のモジュールとして扱われるため、MVS の下位互換性に関する前提が機能します。SemVer
の観点から見ると、A 1.x と A 2.x は異なるモジュールと見なされ、解決された依存関係グラフに共存できます。これは、Go
のパッケージパスにメジャー バージョンがエンコードされているため、コンパイル時やリンク時の競合が発生しないためです。ただし、Bazel はこのような
保証を提供できません。これは、SemVer の緩いバージョンに従っているためです。
そのため、Bazel では、下位互換性のない（破壊的な）バージョンを検出するために、SemVer のメジャー
バージョン番号に相当する番号が必要です。この番号は
互換性レベルと呼ばれ、
module()ディレクティブで各モジュールバージョンによって指定されます。この情報を使用して、
解決された依存関係グラフに
互換性レベルが異なる同じモジュールのバージョンが存在する場合、Bazel はエラーをスローできます。
互換性レベルを上げると、ユーザーに影響が生じる可能性があります。
互換性レベルを上げるタイミングと方法については、MODULE.bazel
に関するよくある質問をご覧ください。
オーバーライド
MODULE.bazel ファイルでオーバーライドを指定して、Bazel モジュール解決の動作を変更します。有効になるのはルート
モジュールのオーバーライドのみです。モジュールが依存関係として使用されている場合、そのオーバーライドは無視されます。
各オーバーライドは特定のモジュール名に対して指定され、依存関係グラフ内のすべてのバージョンに影響します。有効になるのはルート モジュールのオーバーライドのみですが、ルート モジュールが直接依存していない推移的な依存関係に対してオーバーライドを行うことができます。
単一バージョンのオーバーライド
The single_version_override
には複数の目的があります。
version属性を使用すると、依存関係グラフでどのバージョンの依存関係がリクエストされているかに関係なく、依存関係を特定のバージョンに固定できます。registry属性を使用すると、通常の registry selection プロセスに従うのではなく、この依存関係を a specific registry から取得するように強制できます。patch*属性を使用すると、ダウンロードしたモジュールに適用するパッチのセットを指定できます。
これらの属性はすべて省略可能で、組み合わせて使用できます。
複数バージョンのオーバーライド
multiple_version_override
を指定すると、解決された依存関係グラフに同じモジュールの複数のバージョンを共存させることができます。
モジュールで許可されるバージョンの明示的なリストを指定できます。これらのバージョンはすべて、解決前に依存関係グラフに存在する必要があります。つまり、許可される各バージョンに依存する推移的な依存関係がいくつか存在する必要があります。解決後、モジュールの許可されたバージョンのみが残ります。Bazel は、モジュールの他のバージョンを同じ互換性レベルで最も近い上位の許可されたバージョンにアップグレードします。同じ互換性レベルで上位の許可されたバージョンが存在しない場合、Bazel はエラーをスローします。
たとえば、解決前に依存関係グラフにバージョン 1.1、1.3、1.5、1.7、2.0 が存在し、メジャー バージョンが互換性レベルである場合、次のようになります。
1.3、1.7、2.0を許可する複数バージョンのオーバーライドにより、1.1が1.3にアップグレードされ、1.5が1.7にアップグレードされ、他のバージョンは変更されません。1.5と2.0を許可する複数バージョンのオーバーライドでは、1.7にアップグレードできる同じ互換性レベルの上位バージョンがないため、エラーが発生します。1.9と2.0を許可する複数バージョンのオーバーライドでは、解決前に依存関係グラフに1.9が存在しないため、エラーが発生します。
また、単一バージョンのオーバーライドと同様に、registry 属性を使用してレジストリをオーバーライドすることもできます。
非レジストリのオーバーライド
非レジストリのオーバーライドでは、モジュールがバージョンの解決から完全に削除されます。Bazel は、これらの MODULE.bazel
ファイルをレジストリからではなく、リポジトリ自体からリクエストします。
Bazel は、次の非レジストリのオーバーライドをサポートしています。
モジュールが非レジストリのオーバーライドでオーバーライドされている場合、ソース アーカイブ MODULE.bazel
にバージョン値を設定すると、デメリットが生じる可能性があります。詳細については、
に関するよくある質問MODULE.bazel
をご覧ください。
Bazel モジュールを表さないリポジトリを定義する
bazel_dep を使用すると、他の Bazel モジュールを表すリポジトリを定義できます。Bazel
モジュールを表さないリポジトリを定義する必要がある場合があります。たとえば、データとして読み取るプレーン JSON
ファイルを含むリポジトリなどです。
この場合、use_repo_ruleディレクティブを使用して、リポジトリルールを呼び出すことでリポジトリを直接定義できます。このリポジトリは、定義されているモジュールでのみ表示されます。
内部的には、モジュール拡張機能と同じメカニズムを使用して実装されます。これにより、リポジトリをより柔軟に定義できます。
リポジトリ名と厳密な依存関係
モジュールをサポートするリポジトリの直接依存関係に対する表示名は、
repo_name属性がbazel_dep
ディレクティブで指定されていない限り、デフォルトでモジュール名になります。つまり、モジュールは直接依存関係のみを検出できます。これにより、推移的な依存関係の変更による意図しない破損を防ぐことができます。
モジュールをサポートするリポジトリの正規名は、依存関係グラフ全体にモジュールの複数のバージョンがあるかどうかに応じて、module_name+version（bazel_skylib+1.0.3など）またはmodule_name+（bazel_features+など）になります（multiple_version_overrideを参照）。正規名の形式は、依存すべき API ではなく、いつでも変更される可能性があります。正規名をハードコードするのではなく、サポートされている方法で
Bazel から直接取得します。
- BUILD ファイルと
.bzlファイルでは、リポジトリの表示名で指定されたラベル文字列から構築されたLabelインスタンスでLabel.repo_nameを使用します（例:Label("@bazel_skylib").repo_name）。 - 実行ファイルを参照する場合は、
$(rlocationpath ...)または@bazel_tools//tools/{bash,cpp,java}/runfilesの実行ファイル ライブラリのいずれかを使用します。ルールセットrules_fooの場合は、@rules_foo//foo/runfilesを使用します。 - IDE や言語
サーバーなどの外部ツールから Bazel を操作する場合は、
bazel mod dump_repo_mappingコマンドを使用して、指定されたリポジトリの表示名から 正規名へのマッピングを取得します。
モジュール拡張機能を使用すると、モジュールの可視スコープに追加のリポジトリを導入することもできます 。