Bazel モジュールは、それぞれ複数のバージョンを持つことができる Bazel プロジェクトです。 依存関係にある他のモジュールに関するメタデータを公開します。これは、 他の依存関係管理システムにおけるよく知られた概念に似ています。たとえば、依存関係管理システム Maven アーティファクト、npm パッケージ、Go モジュール、または Cargo クレート。
モジュールには、リポジトリのルート（MODULE.bazel
WORKSPACE ファイルなど）。このファイルはモジュールのマニフェストで、名前、
バージョン、直接的な依存関係のリストなどの情報が含まれます。基本的な
例:
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 ファイルを実行し、次に依存関係のリクエストを
Bazel レジストリから MODULE.bazel ファイルを取得します。
依存関係グラフ全体を検出します。
デフォルトでは、Bazel は各モジュールの 1 つのバージョンを選択します 使用できます。Bazel は各モジュールをリポジトリで表し、レジストリを参照します。 各リポジトリの定義方法を学びましょう
バージョン形式
Bazel には多様なエコシステムがあり、プロジェクトではさまざまなバージョニング スキームが使用されています。「
最も人気があるのは SemVer ですが、
さまざまなスキームを使用する著名なプロジェクトも
Abseil
バージョンは日付ベースです（例: 20210324.2）。
そのため、Bzlmod では SemVer 仕様のより緩和されたバージョンを採用しています。「 次のような違いがあります。
- SemVer では、「リリース」3 つの部分で構成されている必要があります。
セグメント:
MAJOR.MINOR.PATCH。Bazel ではこの要件が緩和されているため、 いくつでもセグメントが許可されます - SemVer では、「リリース」セクションの各セグメントは数値のみを使用できます。 Bazel ではこれを緩めて文字も許容しています。 「identifiers」と一致するようにします。「プレリリース版」をなります。
- さらに、メジャー バージョン、マイナー バージョン、パッチ バージョンの増加のセマンティクスは、 適用されます。ただし、互換性レベルを参照してください。 下位互換性の示し方に関する詳細です。
有効な SemVer バージョンとは、有効な Bazel モジュール バージョンのことです。さらに
SemVer バージョン a と b は、次の場合に同じである場合にのみ a < b を比較します。
Bazel モジュール バージョンと比較されます。
バージョンの選択
バージョニングされた依存関係の根幹であるダイヤモンド依存関係の問題を考慮する 管理スペースになります。次のような依存関係グラフがあるとします。
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 ではこのような保証ができないため、「メジャー バージョン」が必要です
下位互換性のないバージョンを検出します。この番号は
互換性レベルがあります。これは、Terraform のモジュール バージョンの各モジュール バージョンで
module() ディレクティブ。この情報により、Bazel は実行時にエラーをスローできます。
同じモジュールのバージョンで、互換性レベルが異なるものが
解決された依存関係グラフに存在します。
オーバーライド
MODULE.bazel ファイルでオーバーライドを指定して、Bazel の動作を変更します。
解決します。ルート モジュールのオーバーライドのみが有効になります。モジュールが
使用した場合、そのオーバーライドは無視されます。
各オーバーライドは特定のモジュール名に対して指定され、そのモジュール名に影響し、 確認できます。ルート モジュールのオーバーライドだけが ルート モジュールで定義されていない推移的依存関係の場合もあれば、 直接依存しています。
単一バージョンのオーバーライド
single_version_override
多岐にわたります。
version属性を使用すると、特定の依存関係に依存関係を固定できます。 リクエストされる依存関係のバージョンにかかわらず、 依存関係グラフを作成します。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 は、次のレジストリ以外のオーバーライドをサポートしています。
Bazel モジュールを表さないリポジトリを定義する
bazel_dep を使用すると、他の Bazel モジュールを表すリポジトリを定義できます。
Bazel を表していないリポジトリを定義する必要がある場合があります
module;たとえば、データとして読み取られるプレーン JSON ファイルを含むファイルなどです。
この場合、use_repo_rule
ディレクティブを使用してリポジトリを直接
リポジトリのルールを呼び出します。このリポジトリは、所属先のモジュールにのみ表示されます
含まれます。
内部的には、これは module 拡張機能を使用すると、より充実したリポジトリを定義できます。 柔軟性が必要です
リポジトリ名と厳格な依存関係
コンテナの背後にあるリポジトリの見かけ上の名前
その直接の依存先にあるモジュール名はデフォルトでそのモジュール名になります。ただし、
bazel_dep の repo_name 属性
示されます。つまり、モジュールはダイレクト レスポンスの
確認します。これにより、変更による偶発的な破損を
推移的依存関係です
バックエンドをバックアップするリポジトリの正規名
モジュールは、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。
* runfile を検索する際は、
$(rlocationpath ...)
または
@bazel_tools//tools/{bash,cpp,java}/runfiles。ルールセット rules_foo の場合は、
（@rules_foo//foo/runfiles）
* IDE や言語などの外部ツールから Bazel を操作する場合
bazel mod dump_repo_mapping コマンドを使用して、マッピングを取得します。
見かけ上、リポジトリ セットの正規名から変わっていきます。
モジュールの拡張機能により、追加のリポジトリを導入することもできます。 スコープに入れることもできます。