Bzlmod 移行ガイド

問題を報告 ソースを表示

WORKSPACE の欠点により、Bzlmod は今後の Bazel リリースで以前の WORKSPACE システムを置き換える予定です。このガイドでは、プロジェクトを Bzlmod に移行し、外部依存関係を取得するための WORKSPACE を削除する方法について説明します。

WORKSPACE と Bzlmod の比較

Bazel の WORKSPACE と Bzlmod は、構文が異なる同様の機能を備えています。このセクションでは、特定の WORKSPACE 機能から Bzlmod に移行する方法について説明します。

Bazel ワークスペースのルートを定義する

WORKSPACE ファイルは、Bazel プロジェクトのソースルートをマークします。この役割は、Bazel バージョン 6.3 以降では MODULE.bazel に置き換えられています。6.3 より前の Bazel バージョンでも、ワークスペースのルートに WORKSPACE または WORKSPACE.bazel ファイルがあり、次のようなコメントが含まれている可能性があります。

• Google Workspace

  # This file marks the root of the Bazel workspace.
  # See MODULE.bazel for external dependencies setup.
  

ワークスペースのリポジトリ名を指定します

• Google Workspace

  workspace 関数は、ワークスペースのリポジトリ名を指定するために使用されます。これにより、ワークスペース内のターゲット //foo:bar を @<workspace name>//foo:bar として参照できます。指定しない場合、ワークスペースのデフォルトのリポジトリ名は __main__ です。

  ## WORKSPACE
  workspace(name = "com_foo_bar")
  

• Bzlmod

  同じワークスペース内のターゲットは、@<repo name> なしの //foo:bar 構文を使用して参照することをおすすめします。ただし、古い構文が必要な場合は、module 関数で指定されたモジュール名をリポジトリ名として使用できます。モジュール名が必要なリポジトリ名と異なる場合は、module 関数の repo_name 属性を使用してリポジトリ名をオーバーライドできます。

  ## MODULE.bazel
  module(
      name = "bar",
      repo_name = "com_foo_bar",
  )
  

外部依存関係を Bazel モジュールとして取得する

依存関係が Bazel プロジェクトである場合、Bazel モジュールで Bzlmod も導入されていれば、Bazel モジュールとして信頼できるはずです。

• Google Workspace

  WORKSPACE では、http_archive または git_repository リポジトリ ルールを使用して、Bazel プロジェクトのソースをダウンロードするのが一般的です。

  ## WORKSPACE
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
  
  http_archive(
      name = "bazel_skylib",
      urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"],
      sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa",
  )
  load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
  bazel_skylib_workspace()
  
  http_archive(
      name = "rules_java",
      urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"],
      sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a",
  )
  load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
  rules_java_dependencies()
  rules_java_toolchains()
  

  ご覧のように、依存関係のマクロから推移的依存関係を読み込む必要があるのは、これが一般的なパターンです。bazel_skylib と rules_java の両方が platoform に依存すると仮定すると、platform 依存関係の正確なバージョンはマクロの順序によって決まります。

• Bzlmod

  Bzlmod では、依存関係が Bazel Central Registry またはカスタム Bazel レジストリで使用可能である限り、bazel_dep ディレクティブを使用して依存関係を使用できます。

  ## MODULE.bazel
  bazel_dep(name = "bazel_skylib", version = "1.4.2")
  bazel_dep(name = "rules_java", version = "6.1.1")
  

  Bzlmod は、MVS アルゴリズムを使用して Bazel モジュールの依存関係を推移的に解決します。したがって、必要な最大バージョンの platform が自動的に選択されます。

依存関係を Bazel モジュールとしてオーバーライドする

ルート モジュールは、Bazel モジュールの依存関係をさまざまな方法でオーバーライドできます。

詳しくは、overridesのセクションをご覧ください。

使用例については、examples リポジトリをご覧ください。

モジュール拡張機能を使用して外部依存関係を取得する

依存関係が Bazel プロジェクトでない場合、またはどの Bazel レジストリでも使用できない場合は、モジュール拡張機能を使用して導入できます。

• Google Workspace

  http_file リポジトリ ルールを使用してファイルをダウンロードします。

  ## WORKSPACE
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  
  http_file(
      name = "data_file",
      url = "http://example.com/file",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )
  

• Bzlmod

  Bzlmod では、定義を .bzl ファイルに移動する必要があります。これにより、移行期間中に WORKSPACE と Bzlmod の間で定義を共有できます。

  ## repositories.bzl
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  def my_data_dependency():
      http_file(
          name = "data_file",
          url = "http://example.com/file",
          sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      )
  

  依存関係マクロを読み込むモジュール拡張機能を実装します。マクロの同じ .bzl ファイルで定義できますが、古い Bazel バージョンとの互換性を維持するため、別の .bzl ファイルで定義することをおすすめします。

  ## extensions.bzl
  load("//:repositories.bzl", "my_data_dependency")
  def _non_module_dependencies_impl(_ctx):
      my_data_dependency()
  
  non_module_dependencies = module_extension(
      implementation = _non_module_dependencies_impl,
  )
  

  リポジトリをルート プロジェクトから参照できるようにするには、MODULE.bazel ファイルでモジュール拡張機能とリポジトリの使用を宣言する必要があります。

  ## MODULE.bazel
  non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies")
  use_repo(non_module_dependencies, "data_file")
  

モジュール拡張との外部依存関係の競合を解決する

プロジェクトでは、呼び出し元からの入力に基づいて外部リポジトリを導入するマクロを提供できます。しかし、依存関係グラフに複数の呼び出し元があり、それらが競合を引き起こしている場合はどうでしょうか。

プロジェクト foo が、version を引数として受け取る次のマクロを提供しているとします。

## repositories.bzl in foo {:#repositories.bzl-foo}
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def data_deps(version = "1.0"):
    http_file(
        name = "data_file",
        url = "http://example.com/file-%s" % version,
        # Omitting the "sha256" attribute for simplicity
    )

• Google Workspace

  WORKSPACE では、@foo からマクロを読み込み、必要なデータ依存関係のバージョンを指定できます。別の依存関係 @bar があるとします。この依存関係も @foo に依存していますが、別のバージョンのデータ依存関係が必要です。

  ## WORKSPACE
  
  # Introduce @foo and @bar.
  ...
  
  load("@foo//:repositories.bzl", "data_deps")
  data_deps(version = "2.0")
  
  load("@bar//:repositories.bzl", "bar_deps")
  bar_deps() # -> which calls data_deps(version = "3.0")
  

  この場合、エンドユーザーは必要なバージョンを取得するために、WORKSPACE 内のマクロの順序を慎重に調整する必要があります。これは、依存関係を解決する有効な方法を提供できないため、WORKSPACE の最大の課題の一つです。

• Bzlmod

  Bzlmod により、プロジェクト foo の作成者はモジュール拡張機能を使用して競合を解決できます。たとえば、すべての Bazel モジュールの中から、データ依存関係に必要な最大バージョンを常に選択することが理にかなっているとします。

  ## extensions.bzl in foo
  load("//:repositories.bzl", "data_deps")
  
  data = tag_class(attrs={"version": attr.string()})
  
  def _data_deps_extension_impl(module_ctx):
      # Select the maximal required version in the dependency graph.
      version = "1.0"
      for mod in module_ctx.modules:
          for data in mod.tags.data:
              version = max(version, data.version)
      data_deps(version)
  
  data_deps_extension = module_extension(
      implementation = _data_deps_extension_impl,
      tag_classes = {"data": data},
  )
  

  ## MODULE.bazel in bar
  bazel_dep(name = "foo", version = "1.0")
  
  foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
  foo_data_deps.data(version = "3.0")
  use_repo(foo_data_deps, "data_file")
  

  ## MODULE.bazel in root module
  bazel_dep(name = "foo", version = "1.0")
  bazel_dep(name = "bar", version = "1.0")
  
  foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
  foo_data_deps.data(version = "2.0")
  use_repo(foo_data_deps, "data_file")
  

  この場合、ルート モジュールにはデータ バージョン 2.0 が必要ですが、依存関係 bar には 3.0 が必要です。foo のモジュール拡張機能はこの競合を正しく解決し、データの依存関係としてバージョン 3.0 を自動的に選択できます。

サードパーティのパッケージ管理システムを統合する

最後のセクションでは、モジュール拡張機能が依存関係グラフから情報を収集し、カスタム ロジックを実行して依存関係を解決し、リポジトリ ルールを呼び出して外部リポジトリを導入する方法を提供します。これにより、ルール作成者は特定の言語のパッケージ マネージャーを統合するルールセットを強化できます。

モジュール拡張機能の使用方法については、モジュール拡張機能のページをご覧ください。

さまざまなパッケージ マネージャーから依存関係を取得するためにすでに Bzlmod を採用しているルールセットのリストを以下に示します。

• rules_jvm_external
• rules_go
• rules_python

疑似パッケージ管理システムを統合する最小限のサンプルは、examples リポジトリにあります。

ホストマシン上のツールチェーンを検出する

Bazel ビルドルールは、ホストマシンで使用可能なツールチェーンを検出する必要がある場合、リポジトリ ルールを使用してホストマシンを検査し、外部リポジトリとしてツールチェーン情報を生成します。

• Google Workspace

  次のようなリポジトリ ルールでシェル ツールチェーンを検出します。

  ## local_config_sh.bzl
  def _sh_config_rule_impl(repository_ctx):
      sh_path = get_sh_path_from_env("SH_BIN_PATH")
  
      if not sh_path:
          sh_path = detect_sh_from_path()
  
      if not sh_path:
          sh_path = "/shell/binary/not/found"
  
      repository_ctx.file("BUILD", """
  load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain")
  sh_toolchain(
      name = "local_sh",
      path = "{sh_path}",
      visibility = ["//visibility:public"],
  )
  toolchain(
      name = "local_sh_toolchain",
      toolchain = ":local_sh",
      toolchain_type = "@bazel_tools//tools/sh:toolchain_type",
  )
  """.format(sh_path = sh_path))
  
  sh_config_rule = repository_rule(
      environ = ["SH_BIN_PATH"],
      local = True,
      implementation = _sh_config_rule_impl,
  )
  

  リポジトリ ルールを WORKSPACE に読み込むことができます。

  ## WORKSPACE
  load("//:local_config_sh.bzl", "sh_config_rule")
  sh_config_rule(name = "local_config_sh")
  

• Bzlmod

  Bzlmod では、モジュール拡張機能を使用して同じリポジトリを導入できます。これは、前のセクションで @data_file リポジトリを導入した場合と同様です。

  ## local_config_sh_extension.bzl
  load("//:local_config_sh.bzl", "sh_config_rule")
  
  sh_config_extension = module_extension(
      implementation = lambda ctx: sh_config_rule(name = "local_config_sh"),
  )
  

  次に、MODULE.bazel ファイル内の拡張子を使用します。

  ## MODULE.bazel
  sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
  use_repo(sh_config_ext, "local_config_sh")
  

ツールチェーンと実行プラットフォームを登録する

最後のセクションのセクションでは、ツールチェーン情報（local_config_sh など）をホストするリポジトリを導入した後で、ツールチェーンを登録することをおすすめします。

• Google Workspace

  WORKSPACE では、次の方法でツールチェーンを登録できます。

  1. ツールチェーンを .bzl ファイルに登録し、WORKSPACE ファイルでマクロを読み込むことができます。

     ## local_config_sh.bzl
     def sh_configure():
         sh_config_rule(name = "local_config_sh")
         native.register_toolchains("@local_config_sh//:local_sh_toolchain")
     

     ## WORKSPACE
     load("//:local_config_sh.bzl", "sh_configure")
     sh_configure()
     

  2. または、ツールチェーンを WORKSPACE ファイルに直接登録します。

     ## WORKSPACE
     load("//:local_config_sh.bzl", "sh_config_rule")
     sh_config_rule(name = "local_config_sh")
     register_toolchains("@local_config_sh//:local_sh_toolchain")
     

• Bzlmod

  Bzlmod では、register_toolchains API と register_execution_platforms API は MODULE.bazel ファイルでのみ使用できます。モジュール拡張機能で native.register_toolchains を呼び出すことはできません。

  ## MODULE.bazel
  sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
  use_repo(sh_config_ext, "local_config_sh")
  register_toolchains("@local_config_sh//:local_sh_toolchain")
  

ローカル リポジトリを導入する

デバッグのために依存関係のローカル バージョンが必要な場合や、外部リポジトリとしてワークスペースにディレクトリを組み込む場合は、依存関係をローカル リポジトリとして導入することが必要な場合があります。

• Google Workspace

  WORKSPACE では、これは local_repository と new_local_repository の 2 つのネイティブ リポジトリ ルールによって実現されます。

  ## WORKSPACE
  local_repository(
      name = "rules_java",
      path = "/Users/bazel_user/workspace/rules_java",
  )
  

• Bzlmod

  Bzlmod では、local_path_override を使用して、ローカルパスでモジュールをオーバーライドできます。

  ## MODULE.bazel
  bazel_dep(name = "rules_java")
  local_path_override(
      module_name = "rules_java",
      path = "/Users/bazel_user/workspace/rules_java",
  )
  

  注: local_path_override では、ローカル ディレクトリを Bazel モジュールとしてのみ導入できます。つまり、MODULE.bazel ファイルが必要であり、依存関係の解決時にその推移的な依存関係が考慮されます。また、モジュール オーバーライド ディレクティブはすべて、ルート モジュールでのみ使用できます。

  モジュール拡張を使用してローカル リポジトリを導入することもできます。ただし、モジュール拡張で native.local_repository を呼び出すことはできません。すべてのネイティブ リポジトリ ルールをスター化する取り組みが進行中です（進行状況は #18285 を確認してください）。次に、対応する Stlark の local_repository をモジュール拡張機能で呼び出すことができます。これがブロック的な問題である場合、local_repository リポジトリ ルールのカスタム バージョンの実装も簡単です。

バインド ターゲット

WORKSPACE の bind ルールは非推奨であり、Bzlmod ではサポートされていません。これは、特別な //external パッケージでターゲットにエイリアスを与えるために導入されました。これに依存しているすべてのユーザーは移行する必要があります。

たとえば チェックアウトマイクロサービスを呼び出す

## WORKSPACE
bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

これにより、他のターゲットが //external:openssl に依存できるようになります。次の方法で移行できます。

• //external:openssl を使用している場合は、すべて @my-ssl//src:openssl-lib に置き換えます。

• または、alias ビルドルールを使用する

  • パッケージで次のターゲットを定義します（例: //third_party）

    ## third_party/BUILD
    alias(
        name = "openssl,
        actual = "@my-ssl//src:openssl-lib",
    )
    

  • //external:openssl を使用している場合は、すべて //third_party:openssl-lib に置き換えます。

移行

このセクションでは、Bzlmod の移行プロセスに役立つ情報とガイダンスについて説明します。

WORKSPACE の依存関係を把握する

移行の最初のステップは、どのような依存関係が存在するかを把握することです。一時的な依存関係は *_deps マクロで読み込まれることが多いため、WORKSPACE ファイルに導入された正確な依存関係を把握するのが難しい場合があります。

ワークスペースの解決済みファイルを使用して外部依存関係を検査する

この場合、--experimental_repository_resolved_file フラグを使用すると便利です。このフラグは基本的に、最後の Bazel コマンドで取得したすべての外部依存関係の「ロックファイル」を生成します。詳しくは、こちらのブログ投稿をご覧ください。

次の 2 つの方法で使用できます。

1. 特定のターゲットをビルドするために必要な外部依存関係の情報を取得する。

   bazel clean --expunge
   bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
   

2. WORKSPACE ファイルで定義されたすべての外部依存関係の情報を取得します。

   bazel clean --expunge
   bazel sync --experimental_repository_resolved_file=resolved.bzl
   

   bazel sync コマンドを使用すると、WORKSPACE ファイルで定義されているすべての依存関係を取得できます。

   • bind 使用状況
   • register_toolchains と register_execution_platforms の使用状況

   ただし、プロジェクトがクロス プラットフォームの場合、特定のプラットフォームで bazel 同期が機能しないことがあります。これは、一部のリポジトリ ルールが、サポートされているプラットフォームでのみ正しく実行されるためです。

このコマンドを実行すると、外部依存関係の情報が resolved.bzl ファイルに格納されます。

bazel query で外部依存関係を検査する

また、bazel query を使用してリポジトリ ルールを検査することもできます。

bazel query --output=build //external:<repo name>

その方が便利で高速ですが、bazel クエリは外部依存関係のバージョンに関係することもあるため、慎重に使用してください。Bzlmod による外部依存関係のクエリと検査は、新しいサブコマンドで行います。

組み込みのデフォルトの依存関係

--experimental_repository_resolved_file によって生成されたファイルをチェックすると、WORKSPACE に定義されていない依存関係が多数見つかります。これは、Bazel がユーザーの WORKSPACE ファイル コンテンツにプレフィックスとサフィックスを追加して、通常はネイティブ ルールで必要とされるデフォルトの依存関係（@bazel_tools、@platforms、@remote_java_tools など）を挿入するためです。Bzlmod では、これらの依存関係は組み込みモジュール bazel_tools で導入されます。これは他のすべての Bazel モジュールのデフォルト依存関係です。

ハイブリッド モードによる段階的な移行

Bzlmod と WORKSPACE は並べて動作できるため、WORKSPACE ファイルから Bzlmod に依存関係を段階的に移行できます。

WORKSPACE.bzlmod

Bazel ユーザーは、移行中、Bzlmod が有効な場合と無効なビルドを切り替える必要があります。プロセスをスムーズにするために、WORKSPACE.bzlmod のサポートが実装されています。

WORKSPACE.bzlmod の構文は WORKSPACE とまったく同じです。Bzlmod が有効になっている場合、ワークスペースのルートに WORKSPACE.bzlmod ファイルも存在する場合は次のようになります。

• WORKSPACE.bzlmod が有効になり、WORKSPACE の内容は無視されます。
• WORKSPACE.bzlmod ファイルにプレフィックスやサフィックスは追加されません。

WORKSPACE.bzlmod ファイルを使用すると、次の理由で移行が簡単になります。

• Bzlmod が無効になっている場合は、元の WORKSPACE ファイルから依存関係の取得にフォールバックします。
• Bzlmod を有効にすると、WORKSPACE.bzlmod を使用して、移行する必要がある依存関係をより正確に追跡できます。

注: WORKSPACE.bzlmod は、ワークスペースのルートを識別する WORKSPACE の機能に代わるものではなく、ワークスペースのルートに WORKSPACE ファイルが必要です。

リポジトリの公開設定

Bzlmod は、特定のリポジトリから他のどのリポジトリを公開するかを制御できます。詳細については、リポジトリ名と厳格な依存関係をご覧ください。

ここでは、WORKSPACE も考慮した場合の、さまざまなタイプのリポジトリにおけるリポジトリの公開設定の概要を示します。

	メイン リポジトリから	Bazel モジュール リポジトリから	モジュール拡張機能リポジトリから	WORKSPACE リポジトリから
メイン リポジトリ	表示	ルート モジュールが直接依存関係の場合	ルート モジュールが、モジュール拡張機能をホストするモジュールに直接依存している場合	表示
Bazel モジュール リポジトリ	直接依存関係	直接依存関係	モジュール拡張機能をホストするモジュールの直接の依存関係	ルート モジュールの直接依存関係
モジュール拡張リポジトリ	直接依存関係	直接依存関係	モジュール拡張機能をホストするモジュールの直接の依存関係 + 同じモジュール拡張機能によって生成されたすべてのリポジトリ	ルート モジュールの直接依存関係
WORKSPACE リポジトリ	表示可能なすべて	表示されません	表示されません	表示可能なすべて

注: ルート モジュールについては、リポジトリ @foo が WORKSPACE で定義され、@foo が MODULE.bazel で見かけ上のリポジトリ名としても使用されている場合、@foo は MODULE.bazel で導入されたモジュールを参照します。

注: モジュール拡張機能で生成されたリポジトリ@barの別のモジュール @foo が、同じリポジトリ名

で生成された@foo@bar

移行プロセス

一般的な Bzlmod 移行プロセスは次のようになります。

1. WORKSPACE にどのような依存関係があるかを把握します。
2. プロジェクトのルートに空の MODULE.bazel ファイルを追加します。
3. 空の WORKSPACE.bzlmod ファイルを追加して、WORKSPACE ファイルの内容をオーバーライドします。
4. Bzlmod を有効にしてターゲットをビルドし、欠落しているリポジトリを確認します。
5. 解決された依存関係ファイルで、欠落しているリポジトリの定義を確認します。
6. 欠落している依存関係を Bazel モジュールとして導入するか、モジュール拡張機能を使用して導入するか、後で移行するために WORKSPACE.bzlmod に残します。
7. 手順 4 に戻って、すべての依存関係が使用可能になるまで繰り返します。

移行ツール

開始時には、インタラクティブな Bzlmod 移行ヘルパー スクリプトを使用できます。

このスクリプトは次の処理を行います。

• WORKSPACE の解決済みファイルを生成して解析します。
• 解決済みファイルのリポジトリ情報を人が読める形式で出力します。
• bazel ビルドコマンドを実行し、認識されたエラー メッセージを検出して、移行方法を推奨します。
• BCR で依存関係がすでに使用可能かどうかを確認します。
• MODULE.bazel ファイルに依存関係を追加します。
• モジュール拡張機能を使用して依存関係を追加します。
• WORKSPACE.bzlmod ファイルに依存関係を追加する。

これを使用するには、最新の Bazel リリースがインストールされていることを確認し、次のコマンドを実行します。

git clone https://github.com/bazelbuild/bazel-central-registry.git
cd <your workspace root>
<BCR repo root>/tools/migrate_to_bzlmod.py -t <your build targets>

注: Bzlmod は進化しているため、移行スクリプトは完全ではなく、最新ではない可能性があります。推奨ソリューションが正確かどうかを必ず再確認してください。

Bazel モジュールを公開する

Bazel プロジェクトが他のプロジェクトの依存関係の場合は、Bazel Central Registry でプロジェクトを公開できます。

BCR でプロジェクトをチェックインできるようにするには、プロジェクトのソース アーカイブ URL が必要です。ソース アーカイブを作成する際は、以下の点に注意してください。

• アーカイブが特定のバージョンを指していることを確認します。

  Bzlmod では依存関係の解決中にバージョンの比較を行う必要があるため、BCR はバージョニングされたソース アーカイブのみを受け入れます。

• アーカイブ URL が安定していることを確認します。

  Bazel は、ハッシュ値でアーカイブの内容を検証するため、ダウンロードしたファイルのチェックサムが変更されないようにする必要があります。URL が GitHub からのものである場合は、リリースページでリリース アーカイブを作成してアップロードしてください。GitHub は、オンデマンドで生成されるソース アーカイブのチェックサムを保証しません。つまり、https://github.com/<org>/<repo>/releases/download/... 形式の URL は安定版と見なされますが、https://github.com/<org>/<repo>/archive/... は安定版ではありません。詳細については、GitHub Archive Checksum のサービス停止をご覧ください。

• ソースツリーが元のリポジトリのレイアウトに従っていることを確認します。

  リポジトリが非常に大きく、不要なソースを削除してサイズを縮小した配布アーカイブを作成する場合は、削除したソースツリーが元のソースツリーのサブセットであることを確認してください。これにより、エンドユーザーが archive_override と git_override によってモジュールを非リリース バージョンに簡単にオーバーライドできるようになります。

• 最も一般的な API をテストするテスト モジュールをサブディレクトリに追加します。

  テスト モジュールは、公開する実際のモジュールに依存するソース アーカイブのサブディレクトリにある独自の WORKSPACE ファイルと MODULE.bazel ファイルを持つ Bazel プロジェクトです。これには、最も一般的な API をカバーするサンプルまたはいくつかの統合テストが含まれている必要があります。設定方法については、テスト モジュールをご覧ください。

ソース アーカイブ URL の準備ができたら、BCR コントリビューション ガイドラインに沿って、GitHub pull リクエストとともにモジュールを BCR に送信します。

モジュールを BCR に送信するプロセスを自動化するために、リポジトリの BCR に公開 GitHub アプリを設定することを強くおすすめします。

ベスト プラクティス

このセクションでは、外部依存関係を適切に管理するためのベスト プラクティスをいくつか紹介します。

不要な依存関係を取得しないように、ターゲットを異なるパッケージに分割します。

#12835 を確認します。ここでは、テストの開発環境の依存関係が、必要のないターゲットのビルドのために不必要に取得されます。これは実際には Bzlmod 固有ではありませんが、この方法に従うと、開発の依存関係を正しく指定しやすくなります。

開発環境の依存関係を指定する

bazel_dep ディレクティブと use_extension ディレクティブの dev_dependency 属性を true に設定すると、依存プロジェクトには反映されません。ルート モジュールとして --ignore_dev_dependency フラグを使用すると、ターゲットが開発環境の依存関係なしでまだビルドされているかどうかを確認できます。

コミュニティの移行の進行状況

Bazel Central Registry で、依存関係がすでに利用可能かどうかを確認できます。または、こちらの GitHub のディスカッションに参加して、移行の妨げとなっている依存関係に賛成または投稿してください。

問題を報告する

Bzlmod の既知の問題については、Bazel GitHub 問題リストをご覧ください。新しい問題や機能リクエストを提出して、移行の障害を解消してください。