安定版リリースのドキュメントについては、[バージョニングされたドキュメント] プルダウンを使用してください。デフォルトのビューには HEAD の最新バージョンが表示されます。

このページは Cloud Translation API によって翻訳されました。

モジュール拡張機能

モジュール拡張機能を使用すると、依存関係グラフ全体のモジュールから入力データを読み取り、依存関係を解決するために必要なロジックを実行して、最後にリポジトリルールを呼び出してリポジトリを作成することで、モジュールシステムを拡張できます。これらの拡張機能にはリポジトリルールに似た機能があり、ファイル I/O の実行、ネットワークリクエストの送信などを行うことができます。特に、Bazel モジュールから構築された依存関係グラフを尊重しながら、Bazel が他のパッケージ管理システムとやり取りできるようになります。

リポジトリルールと同様に、モジュール拡張子を .bzl ファイルで定義できます。これらは直接呼び出されるのではなく、各モジュールが拡張機能が読み取るタグと呼ばれるデータを指定します。Bazel は、拡張機能を評価する前にモジュールの解決を実行します。この拡張機能は、依存関係グラフ全体で自身に属するすべてのタグを読み取ります。

拡張機能の使用状況

拡張機能は Bazel モジュール自体でホストされます。モジュールで拡張機能を使用するには、まず拡張機能をホストするモジュールに bazel_dep を追加してから、use_extension 組み込み関数を呼び出してスコープに追加します。次の例について考えてみましょう。rules_jvm_external モジュールで定義された「maven」拡張機能を使用する MODULE.bazel ファイルのスニペットです。

bazel_dep(name = "rules_jvm_external", version = "4.5")
maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")

これにより、use_extension の戻り値が変数にバインドされます。これにより、ユーザーはドット構文を使用して拡張機能のタグを指定できます。タグは、拡張機能の定義で指定された対応するタグクラスで定義されたスキーマに従う必要があります。maven.install タグと maven.artifact タグを指定する例を次に示します。

maven.install(artifacts = ["org.junit:junit:4.13.2"])
maven.artifact(group = "com.google.guava",
               artifact = "guava",
               version = "27.0-jre",
               exclusions = ["com.google.j2objc:j2objc-annotations"])

拡張機能によって生成されたリポジトリを現在のモジュールのスコープに含めるには、use_repo ディレクティブを使用します。

use_repo(maven, "maven")

拡張機能によって生成されたリポジトリは、拡張機能の API の一部です。この例では、「maven」モジュール拡張機能により、maven というリポジトリの生成が保証されています。上記の宣言により、拡張機能は「maven」拡張機能によって生成されたリポジトリを指すように @maven//:org_junit_junit などのラベルを適切に解決します。

拡張機能の定義

module_extension 関数を使用して、リポジトリルールと同様にモジュール拡張機能を定義できます。ただし、Repo ルールには多くの属性がありますが、モジュール拡張機能には tag_class があり、各属性には複数の属性があります。タグクラスは、この拡張機能で使用されるタグのスキーマを定義します。たとえば、上記の「maven」拡張機能は次のように定義できます。

# @rules_jvm_external//:extensions.bzl

_install = tag_class(attrs = {"artifacts": attr.string_list(), ...})
_artifact = tag_class(attrs = {"group": attr.string(), "artifact": attr.string(), ...})
maven = module_extension(
  implementation = _maven_impl,
  tag_classes = {"install": _install, "artifact": _artifact},
)

これらの宣言は、指定された属性スキーマを使用して maven.install タグと maven.artifact タグを指定できることを表しています。

モジュール拡張機能の実装関数は、拡張機能とすべての関連タグを使用するすべてのモジュールへのアクセスを許可する module_ctx オブジェクトを取得する点を除き、リポジトリルールの実装関数と似ています。次に、実装関数が Repo ルールを呼び出して、リポジトリを生成します。

# @rules_jvm_external//:extensions.bzl

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")  # a repo rule
def _maven_impl(ctx):
  # This is a fake implementation for demonstration purposes only

  # collect artifacts from across the dependency graph
  artifacts = []
  for mod in ctx.modules:
    for install in mod.tags.install:
      artifacts += install.artifacts
    artifacts += [_to_artifact(artifact) for artifact in mod.tags.artifact]

  # call out to the coursier CLI tool to resolve dependencies
  output = ctx.execute(["coursier", "resolve", artifacts])
  repo_attrs = _process_coursier_output(output)

  # call repo rules to generate repos
  for attrs in repo_attrs:
    http_file(**attrs)
  _generate_hub_repo(name = "maven", repo_attrs)

拡張機能の ID

モジュール拡張子は、名前と use_extension の呼び出しに表示される .bzl ファイルによって識別されます。次の例では、拡張子 maven は .bzl ファイル @rules_jvm_external//:extension.bzl と名前 maven によって識別されます。

maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")

別の .bzl ファイルから拡張機能を再度エクスポートすると、新しい ID が付与され、両方のバージョンの拡張機能が推移的モジュールグラフで使用されている場合は、個別に評価され、その特定の ID に関連付けられたタグのみが表示されます。

拡張機能の作成者は、ユーザーが 1 つの .bzl ファイルに含まれるモジュール拡張機能のみを使用するようにする必要があります。

リポジトリ名と公開設定

拡張機能によって生成されたリポジトリには、module_repo_canonical_name~extension_name~repo_name 形式の正規名が付けられます。ルートモジュールでホストされている拡張機能の場合、module_repo_canonical_name の部分は文字列 _main に置き換えられます。正規名の形式は依存すべき API ではなく、いつでも変更される可能性があります。

この命名ポリシーにより、各拡張機能には独自の「リポジトリ名前空間」があります。2 つの異なる拡張機能で、競合のリスクなしに、それぞれ同じ名前のリポジトリを定義できます。また、repository_ctx.name はリポジトリの正規名を報告しますが、これはリポジトリルール呼び出しで指定された名前とは異なります。

モジュール拡張機能によって生成されたリポジトリを考慮すると、いくつかのリポジトリ可視性ルールがあります。

Bazel モジュールリポジトリは、bazel_dep と use_repo を介して MODULE.bazel ファイルに導入されたすべてのリポジトリを確認できます。
モジュール拡張機能によって生成されたリポジトリは、拡張機能をホストするモジュールに表示されるすべてのリポジトリに加えて、同じモジュール拡張機能によって生成された他のすべてのリポジトリ（見かけ上の名前としてリポジトリルール呼び出しで指定された名前を使用）を表示できます。
- これにより競合が発生する可能性があります。モジュールリポジトリに見かけ上の名前 foo のリポジトリが表示され、拡張機能が指定された名前 foo のリポジトリを生成する場合、その拡張機能によって生成されたすべてのリポジトリでは、foo は前者を参照します。

ベストプラクティス

このセクションでは、拡張機能を簡単に使用し、保守しやすく、時間の経過に伴う変更にうまく適応できるように、拡張機能を作成する際のベストプラクティスについて説明します。

拡張機能ごとに別々のファイルを作成する

拡張機能が別のファイルにある場合、ある拡張機能が別の拡張機能によって生成されたリポジトリを読み込むことができます。この機能を使用しない場合でも、後で必要になる場合に備えて、個別のファイルに保存することをおすすめします。これは、拡張機能の ID がそのファイルに基づいているためです。拡張機能を別のファイルに移動すると、後で公開 API が変更され、ユーザーにとって下位互換性のない変更になるためです。

オペレーティングシステムとアーキテクチャを指定する

拡張機能がオペレーティングシステムまたはそのアーキテクチャタイプに依存している場合は、拡張機能の定義で os_dependent および arch_dependent ブール値属性を使用して、そのことを指定します。これにより、Bazel は、いずれかに変更があった場合に再評価の必要性を認識します。

リポジトリ名に直接影響するのはルートモジュールのみである

拡張機能によってリポジトリが作成されると、拡張機能の名前空間内に作成されることに注意してください。つまり、異なるモジュールが同じ拡張機能を使用して、最終的に同じ名前のリポジトリを作成すると、競合が発生する可能性があります。これは多くの場合、リポジトリルールの name 値として渡される name 引数を持つモジュール拡張機能の tag_class として現れます。

たとえば、ルートモジュール A がモジュール B に依存しているとします。どちらのモジュールもモジュール mylang に依存しています。A と B の両方が mylang.toolchain(name="foo") を呼び出すと、どちらも mylang モジュール内に foo という名前のリポジトリを作成しようとし、エラーが発生します。

これを回避するには、リポジトリ名を直接設定する機能を削除するか、ルートモジュールにのみ許可してください。ルートモジュールには何も依存しないため、この機能を許可しても問題ありません。そのため、別のモジュールが競合する名前を作成することを心配する必要はありません。