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.
bazelrc で Bzlmod を有効にする
.bazelrc
を使用すると、Bazel を実行するたびに適用されるフラグを設定できます。Bzlmod を有効にするには、--enable_bzlmod
フラグを使用して common
コマンドに適用し、すべてのコマンドに適用されるようにします。
.bazelrc
# Enable Bzlmod for every Bazel command common --enable_bzlmod
ワークスペースのリポジトリ名を指定します
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 プロジェクトの場合、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
の両方がplatform
に依存すると仮定した場合、platform
依存関係の正確なバージョンは、マクロの順序によって決まります。bzlmod
Bzlmod では、依存関係が Bazel セントラル レジストリまたはカスタムの 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のセクションをご覧ください。
使用例については、サンプル リポジトリをご覧ください。
モジュール拡張機能を使用して外部依存関係を取得する
依存関係が 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 を採用しているルールセットのリストを次に示します。
疑似パッケージ マネージャーを統合する最小限の例は、例リポジトリにあります。
ホストマシン上のツールチェーンを検出する
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 では次の方法でツールチェーンを登録できます。
ツールチェーンを
.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()
または、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")
WORKSPACE
、WORKSPACE.bzlmod
、各 Bazel モジュールの MODULE.bazel
ファイルに登録されているツールチェーンと実行プラットフォームは、ツールチェーンの選択時に次の優先順位に従います(降順)。
- ルート モジュールの
MODULE.bazel
ファイルに登録されているツールチェーンと実行プラットフォームから構成されます。 WORKSPACE
またはWORKSPACE.bzlmod
ファイルに登録されたツールチェーンと実行プラットフォームを指します。- ルート モジュールの(推移的な)依存関係であるモジュールによって登録されたツールチェーンと実行プラットフォーム。
WORKSPACE.bzlmod
を使用していない場合:WORKSPACE
サフィックスに登録されているツールチェーン。
ローカル リポジトリを導入する
デバッグに依存関係のローカル バージョンが必要な場合や、ワークスペースに外部リポジトリとしてディレクトリを組み込む場合は、ローカル リポジトリとして依存関係を導入する必要があります。
Google Workspace
WORKSPACE では、2 つのネイティブ リポジトリ ルール(
local_repository
とnew_local_repository
)を使用します。## 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", )
モジュール拡張を使用してローカル リポジトリを導入することもできます。 ただし、モジュール拡張機能で
native.local_repository
を呼び出すことはできません。現在、すべてのネイティブ リポジトリ ルールをスター化するための取り組みが進行中です(進行状況については #18285 をご覧ください)。 その後、モジュール拡張機能で対応するスターラークの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 つの方法で使用できます。
特定のターゲットのビルドに必要な外部依存関係の情報を取得するため。
bazel clean --expunge bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
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 を使用して、移行する依存関係をより適切に追跡できます。
リポジトリの公開設定
Bzlmod は、特定のリポジトリから表示できる他のリポジトリを制御できます。詳細については、リポジトリ名と厳密な依存関係をご覧ください。
ここでは、WORKSPACE も考慮した場合の、さまざまな種類のリポジトリのリポジトリの公開設定の概要を示します。
メイン リポジトリから | Bazel モジュール リポジトリから | モジュール拡張機能リポジトリから | WORKSPACE リポジトリから | |
---|---|---|---|---|
メイン リポジトリ | visible | ルート モジュールが直接的な依存関係である場合、 | ルート モジュールが、モジュール拡張機能をホストするモジュールの直接的な依存関係である場合 | visible |
Bazel モジュール リポジトリ | Direct の依存関係 | Direct の依存関係 | モジュール拡張機能をホストするモジュールの直接の依存関係 | ルート モジュールの直接の依存関係 |
モジュール拡張機能リポジトリ | Direct の依存関係 | Direct の依存関係 | モジュール拡張機能をホストするモジュールと、同じモジュール拡張機能によって生成されたすべてのリポジトリの直接の依存関係 | ルート モジュールの直接の依存関係 |
Workspace リポジトリ | すべて表示可能 | 非表示 | 非表示 | すべて表示可能 |
移行プロセス
一般的な Bzlmod 移行プロセスは次のようになります。
- WORKSPACE における依存関係を把握します。
- プロジェクトのルートに空の MODULE.bazel ファイルを追加します。
- 空の WORKSPACE.bzlmod ファイルを追加して、WORKSPACE ファイルの内容をオーバーライドする。
- Bzlmod を有効にしてターゲットをビルドし、欠落しているリポジトリを確認します。
- 解決された依存関係ファイルで欠落しているリポジトリの定義を確認します。
- 不足している依存関係を Bazel モジュールとして、モジュール拡張機能を使用して導入するか、後で移行するために WORKSPACE.bzlmod に残します。
- 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>
Bazel モジュールを公開する
Bazel プロジェクトが他のプロジェクトの依存関係になっている場合は、プロジェクトを Bazel Central Registry に公開できます。
BCR にプロジェクトをチェックインするには、プロジェクトのソース アーカイブ URL が必要です。ソース アーカイブを作成する際は、次の点に注意してください。
アーカイブが特定のバージョンを参照していることを確認します。
依存関係の解決時に Bzlmod がバージョンの比較を行う必要があるため、BCR はバージョニングされたソース アーカイブのみを受け入れることができます。
アーカイブの URL が安定していることを確認する。
Bazel はハッシュ値によってアーカイブの内容を検証するため、ダウンロードしたファイルのチェックサムが変更されないようにする必要があります。GitHub の URL の場合は、リリースページでリリース アーカイブを作成してアップロードしてください。GitHub は、オンデマンドで生成されたソース アーカイブのチェックサムを保証しません。簡単に言うと、
https://github.com/<org>/<repo>/releases/download/...
形式の URL は不変とみなされますが、https://github.com/<org>/<repo>/archive/...
は不変です。詳しくは、GitHub アーカイブ チェックサムのサービス停止をご覧ください。ソースツリーが元のリポジトリのレイアウトに従っていることを確認します。
リポジトリが非常に大きく、不要なソースを除去してサイズを縮小したディストリビューション アーカイブを作成する場合は、除去されたソースツリーが元のソースツリーのサブセットであることを確認してください。これにより、エンドユーザーは
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 の問題リストをご覧ください。移行の障害となる問題や機能リクエストがありましたら、お気軽にお知らせください。