Bazel のモジュール は、複数のバージョンを持つことができる Bazel プロジェクトです。各 バージョンは、依存する他のモジュールに関するメタデータを公開します。これは、Maven の アーティファクト、npm の パッケージ、Go の モジュール、Cargo の クレートなど、他の依存関係管理システムの概念に似ています。
モジュールには、リポジトリのルート（
WORKSPACE ファイルの横）に 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 のように異なるスキームを使用するプロジェクトもあります。Abseil のバージョンは日付ベース（20210324.2 など）です。
このため、Bzlmod では SemVer 仕様のより緩いバージョンを採用しています。 違いは次のとおりです。
- SemVer では、バージョンの「リリース」部分は 3
つのセグメントで構成する必要があります:
MAJOR.MINOR.PATCH. Bazel では、この要件が緩和され、 任意の数のセグメントを使用できます。 - SemVer では、「リリース」部分の各セグメントは数字のみで構成する必要があります。 Bazel では、文字も使用できるようになり、比較 セマンティクスは「プリリリース」部分の「識別子」と一致します。
- また、メジャー バージョン、マイナー バージョン、パッチ バージョンの増加のセマンティクスは 適用されません。ただし、下位互換性の表記方法については、 互換性レベルをご覧ください。
有効な SemVer バージョンは、有効な Bazel モジュール バージョンです。また、2 つの
SemVer バージョン a と b は、Bazel モジュール バージョンとして比較した場合と同じ場合にのみ a < b と比較されます。
バージョンの選択
バージョン管理された依存関係 管理スペースの定番であるダイヤモンド依存関係の問題について考えてみましょう。次のような依存関係グラフがあるとします。
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
使用する D のバージョンはどれですか？この問題を解決するため、Bzlmod は
最小バージョン選択
（MVS）アルゴリズムを Go モジュール システムで導入された使用します。MVS は、モジュールの新しい
バージョンはすべて下位互換性があることを前提として、依存関係（この例では D 1.1）で指定された最も新しいバージョン
を選択します。`D 1.1` は要件を満たすことができる最も古いバージョンであるため、「最小」と呼ばれます。
`D 1.2` 以降が存在しても、選択されません。MVS を使用すると、
忠実度が高く再現可能なバージョンの選択プロセスが作成されます。
ヤンクされたバージョン
レジストリは、回避する必要があるバージョン（セキュリティの脆弱性など）をヤンクとして宣言できます
。Bazel は、モジュールの
ヤンクされたバージョンを選択するとエラーをスローします。このエラーを修正するには、新しい
ヤンクされていないバージョンにアップグレードするか、
--allow_yanked_versions
フラグを使用してヤンクされたバージョンを明示的に許可します。
互換性レベル
Go では、MVS の下位互換性に関する前提は、
モジュールの下位互換性のないバージョンを別のモジュールとして扱うため、機能します。SemVer の観点からすると、A 1.x と A 2.x は異なるモジュールと見なされ、解決された依存関係グラフに共存できます。これは、Go のパッケージ パスにメジャー バージョンをエンコードすることで可能になり、コンパイル時やリンク時の競合が発生しません。
ただし、Bazel はこのような保証を提供できないため、下位互換性のないバージョンを検出するには「メジャー バージョン」
番号が必要です。この番号は
互換性レベルと呼ばれ、各モジュール バージョンの
module() ディレクティブで指定されます。この情報を使用して、Bazel は、解決された依存関係グラフに互換性レベルが異なる同じモジュールのバージョンが存在することを検出すると、エラーをスローできます。
オーバーライド
MODULE.bazel ファイルでオーバーライドを指定して、Bazel
モジュール解決の動作を変更します。有効になるのはルート モジュールのオーバーライドのみです。モジュールが
依存関係として使用されている場合、そのオーバーライドは無視されます。
各オーバーライドは特定のモジュール名に対して指定され、依存関係グラフ内のすべての バージョンに影響します。有効になるのはルート モジュールのオーバーライドのみですが、ルート モジュールが直接依存していない推移的な依存関係に対してオーバーライドを行うことができます。
単一バージョンのオーバーライド
The single_version_override
には複数の目的があります。
version属性を使用すると、依存関係グラフでリクエストされた依存関係のバージョンに関係なく、依存関係を特定の バージョンに固定できます。registry属性を使用すると、通常の registry selection プロセスに従うのではなく、この依存関係を特定のレジストリから強制的に取得できます。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 は、次の非レジストリのオーバーライドをサポートしています。
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.repo_name を Label インスタンスで
使用します。これは、リポジトリの表示名で指定されたラベル文字列から構築されます（例:
Label("@bazel_skylib").repo_name.
* runfiles を検索する場合は、
$(rlocationpath ...)
または
@bazel_tools//tools/{bash,cpp,java}/runfiles の runfiles ライブラリのいずれかを使用します。ルールセット rules_foo の場合は、
@rules_foo//foo/runfiles を使用します。
* IDE や言語
サーバーなどの外部ツールから Bazel を操作する場合は、bazel mod dump_repo_mapping コマンドを使用して、特定のリポジトリのセットの表示名から正規名へのマッピングを取得します。
モジュール拡張機能を使用すると、モジュールの可視スコープに追加のリポジトリを導入することもできます 。