Bzlmod は、Bazel モジュールのデータベースである Bazel レジストリから情報をリクエストして、依存関係を検出します。現在、Bzlmod は インデックス レジストリ__のみをサポートしています。これは、特定の形式に従ったローカル ディレクトリまたは静的 HTTP サーバーです。
インデックス レジストリ
インデックス レジストリは、モジュールのリストに関する情報(ホームページ、メンテナー、各バージョンの MODULE.bazel ファイル、各バージョンのソースを取得する方法など)を含むローカル ディレクトリまたは静的 HTTP サーバーです。特に、ソースアーカイブ自体を提供する必要はありません。
インデックス レジストリは次の形式に従う必要があります。
/bazel_registry.json: レジストリのメタデータを含む JSON ファイル。例:mirrors: ソースアーカイブに使用するミラーのリストを指定します。 ミラーリングされた URL は、ミラー自体と、プロトコルを除いたsource.jsonファイルで指定されたモジュールのソース URL を連結したものです。たとえば、モジュールのソース URL がhttps://foo.com/bar/bazで、mirrorsに["https://mirror1.com/", "https://example.com/mirror2/"]が含まれている場合、 Bazel が試行する URL はhttps://mirror1.com/foo.com/bar/baz、https://example.com/mirror2/foo.com/bar/baz、最後に元の ソース URLhttps://foo.com/bar/bazの順になります。module_base_path:source.jsonファイルでlocal_repositoryタイプのモジュールのベースパスを指定します。
/modules: このレジストリ内の各モジュールのサブディレクトリを含むディレクトリ/modules/$MODULE: このモジュールの各バージョンのサブディレクトリを含むディレクトリ。次のものも含まれます。metadata.json: モジュールに関する情報を含む JSON ファイル。次のフィールドがあります。homepage: プロジェクトのホームページの URLmaintainers: JSON オブジェクトのリスト。各オブジェクトは、レジストリ内のモジュールのメンテナーの情報に対応します。 これは、プロジェクトの作成者 と同じであるとは限りません。versions: このレジストリで見つかるこのモジュールのすべてのバージョンのリストyanked_versions: このモジュールの取り消された バージョンのマップ。キーは取り消すバージョン、値はバージョンが取り消された理由の説明です。できれば詳細情報へのリンクを含めます。
/modules/$MODULE/$VERSION: 次のファイルを含むディレクトリ。MODULE.bazel: このモジュール バージョンのMODULE.bazelファイルsource.json: このモジュール バージョンのソースを取得する方法に関する情報を含む JSON ファイル- デフォルトのタイプは「archive」で、
http_archiveリポジトリを表します。次のフィールドがあります。url: ソースアーカイブの URLintegrity: アーカイブの Subresource Integrity チェックサムstrip_prefix: ソースアーカイブを抽出するときに削除するディレクトリ プレフィックスpatches: 抽出したアーカイブに適用するパッチファイルを含むマップ。パッチファイルは/modules/$MODULE/$VERSION/patchesディレクトリにあります。キーはパッチファイル名、値はパッチファイルの整合性チェックサムです。patch_strip: Unixpatchの--strip引数と同じです。archive_type:ダウンロードしたファイルのアーカイブ タイプ(http_archiveのtypeと同じ)。 デフォルトでは、アーカイブ タイプは URL のファイル拡張子から決定されます。ファイルに 拡張子がない場合は、"zip"、"jar"、"war"、"aar"、"tar"、"tar.gz"、"tgz"、"tar.xz"、"txz"、"tar.zst"、"tzst"、tar.bz2、"ar"、または"deb"のいずれかを明示的に指定できます。
- タイプを変更して Git リポジトリを使用できます。次のフィールドがあります。
type:git_repository- https://bazel.build/rules/lib/repo/git に記載されている次のフィールド。
remotecommitshallow_sincetaginit_submodulesverbosestrip_prefix
- タイプを変更してローカルパスを使用できます。これは
local_repositoryリポジトリを表します。次のフィールドがあります。type:local_pathpath: リポジトリのローカルパス。次のように計算されます。pathが絶対パスの場合はそのままpathが相対パスで、module_base_pathが絶対パスの場合は、<module_base_path>/<path>に解決されます。pathとmodule_base_pathの両方が相対パスの場合は、<registry_path>/<module_base_path>/<path>に解決されます。 レジストリはローカルでホストされ、--registry=file://<registry_path>で使用する必要があります。そうしないと、Bazel はエラーをスローします。
- デフォルトのタイプは「archive」で、
patches/: パッチファイルを含むオプションのディレクトリ。source.jsonのタイプが「archive」の場合にのみ使用されます。
metadata.json
metadata.json は、モジュールに関する情報を含むオプションの JSON ファイルです。次のフィールドがあります。
versions: 文字列の配列。それぞれがこのレジストリで使用可能なモジュールのバージョンを示します。この配列は、モジュール ディレクトリの子と一致する必要があります。yanked_versions: このモジュールの取り消された バージョンを指定する JSON オブジェクト。キーは取り消すバージョン、値はバージョンが取り消された理由の説明です。できれば詳細情報へのリンクを含めます。
BCR では、metadata.json ファイルにさらに多くの情報が必要です。
source.json
source.json は、モジュールの特定のバージョンを取得する方法に関する情報を含む必須の JSON ファイルです。このファイルのスキーマは type フィールドによって異なります。デフォルトは archive です。
typeがarchive(デフォルト)の場合、このモジュール バージョンはhttp_archiveリポジトリルールによってバックアップされます。指定された URL からアーカイブをダウンロードしてその内容を抽出することで取得されます。次のフィールドがサポートされています。url: 文字列。ソースアーカイブの URLmirror_urls: 文字列のリスト。ソースアーカイブのミラー URL。 URL は、バックアップとしてurlの後に順番に試行されます。integrity: 文字列。アーカイブの [Subresource Integrity][subresource-integrity] チェックサムstrip_prefix: 文字列。ソースアーカイブを抽出するときに削除するディレクトリ プレフィックスoverlay: 抽出したアーカイブの上に重ねるオーバーレイ ファイルを含む JSON オブジェクト。パッチファイルは/modules/$MODULE/$VERSION/overlayディレクトリにあります。キーはオーバーレイ ファイル名、値はオーバーレイ ファイルの整合性チェックサムです。オーバーレイはパッチファイルの前に適用されます。patches: 抽出したアーカイブに適用するパッチファイルを含む JSON オブジェクト。パッチファイルは/modules/$MODULE/$VERSION/patchesディレクトリにあります。キーはパッチファイル名、値はパッチファイルの整合性チェックサムです。パッチはオーバーレイ ファイルの後に適用されます。patch_strip: 数値。Unixpatchの--strip引数と同じです。archive_type: 文字列。ダウンロードしたファイルのアーカイブ タイプ(typeのhttp_archiveと同じ)。
typeがgit_repositoryの場合、このモジュール バージョンはgit_repositoryリポジトリルールによってバックアップされます。Git リポジトリをクローンすることで取得されます。- 次のフィールドがサポートされており、基盤となる
git_repositoryリポジトリルールに直接転送されます。remote、commit、shallow_since、tag、init_submodules、verbose、strip_prefix。
- 次のフィールドがサポートされており、基盤となる
typeがlocal_pathの場合、このモジュール バージョンはlocal_repositoryリポジトリルールによってバックアップされます。 ローカル ディスク上のディレクトリにシンボリック リンクされます。次のフィールドがサポートされています。path: リポジトリのローカルパス。次のように計算されます。pathが絶対パスの場合はそのままpathが相対パスで、module_base_pathが絶対パスの場合は、<module_base_path>/<path>に解決されます。pathとmodule_base_pathの両方が相対パスの場合は、<registry_path>/<module_base_path>/<path>に解決されます。 レジストリはローカルでホストされ、--registry=file://<registry_path>で使用する必要があります。そうしないと、Bazel はエラーをスローします。
Bazel Central Registry
https://bcr.bazel.build/ にある Bazel Central Registry(BCR)は、GitHub リポジトリbazelbuild/bazel-central-registry によってバックアップされたコンテンツを含むインデックス レジストリです。https://registry.bazel.build/ のウェブ フロントエンドを使用して、その内容を閲覧できます。
BCR は Bazel コミュニティによって管理されており、投稿者はプルリクエストを送信できます。BCR の投稿 ガイドラインをご覧ください。
通常のインデックス レジストリの形式に従うだけでなく、BCR では
各モジュール バージョン(/modules/$MODULE/$VERSION/presubmit.yml)に presubmit.yml ファイルが必要です。このファイルでは、このモジュール バージョンの有効性を確認するために使用できる、いくつかの重要な
ビルド ターゲットとテスト ターゲットを指定します。BCR の CI パイプラインでも、モジュール間の相互運用性を確保するために使用されます。
レジストリを選択する
繰り返し可能な Bazel フラグ --registry を使用すると、モジュールをリクエストするレジストリのリストを指定できます。これにより、サードパーティまたは内部レジストリから依存関係を取得するようにプロジェクトを設定できます。以前のレジストリが優先されます。便宜上、--registry フラグのリストをプロジェクトの .bazelrc ファイルに配置できます。
レジストリが GitHub でホストされている場合(たとえば、bazelbuild/bazel-central-registry のフォークとして)、--registry 値には raw.githubusercontent.com の下の GitHub の生の URL が必要です。たとえば、main
フォークの my-org ブランチでは、
--registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/ を設定します。
--registry フラグを使用すると、Bazel Central Registry がデフォルトで使用されなくなりますが、--registry=https://bcr.bazel.build を追加することで元に戻すことができます。