Bazel は、外部依存関係、使用するソースファイル(テキストとバイナリの両方)をサポートしています。 自動的に作成されます。たとえば、 GitHub リポジトリ、Maven アーティファクト、またはローカルのディレクトリでホストされている 現在のワークスペースから移動することはできません。
Bazel 6.0 以降では、Bazel で外部依存関係を管理する方法が 2 つあります。
従来のリポジトリを中心とした WORKSPACE
システム
モジュールに焦点を当てた新しい MODULE.bazel
システム(コードネーム Bzlmod、
フラグ --enable_bzlmod
で有効にします)。この 2 つのシステムは
ただし、将来的に Bazel で WORKSPACE
システムを置き換えるのは Bzlmod です。
移行方法については、Bzlmod 移行ガイドをご覧ください。
移行できます。
このドキュメントでは、外部依存関係の管理に関するコンセプトについて説明します。 2 つのシステムについて詳しく見ていきましょう
コンセプト
リポジトリ
ソースを含む WORKSPACE
または WORKSPACE.bazel
ファイルがあるディレクトリ
Bazel ビルドで使用するファイルを指定します。多くの場合、リポのために短縮されます。
メイン リポジトリ
現在の Bazel コマンドが実行されているリポジトリ。
ワークスペース
すべての Bazel コマンドで共有される環境は、同じメイン リポジトリで実行されます。
これまで「リポジトリ」のコンセプトはと「workspace」を 混同し、“Workspace”という用語はよく使われるのは 「repository」の同義語として使われることさえあります。
正規リポジトリ名
リポジトリをアドレス指定できる正規名。これは、
各リポジトリに 1 つの正規名があります。リポジトリ内のターゲット
正規名が canonical_name
であれば、そのラベルは正規名をアドレスとして指定できます
@@canonical_name//pac/kage:target
(二重の @
に注意)。
メイン リポジトリでは、正規名として常に空の文字列が使用されます。
わかりやすいリポジトリ名
リポジトリの名前。他のリポジトリのコンテキストで参照できます。
これは、リポジトリの「ニックネーム」と考えることができます。正規名を持つリポジトリ
michael
は、リポジトリのコンテキストでは mike
という名前になります。
alice
。ただし、リポジトリのコンテキストでは mickey
という名前になっている場合があります。
bob
。この場合、michael
内のターゲットはラベルでアドレス指定できます。
alice
のコンテキストの @mike//pac/kage:target
(単一の @
に注意)。
逆に、これはリポジトリ マッピング、つまり各リポジトリと理解することもできます。 「明らかなリポジトリ名」からのマッピングが維持される「正規リポジトリ名」に変更します。
リポジトリ ルール
コンテナを実体化する方法を Bazel に指示するリポジトリ定義のスキーマ
できます。たとえば、「特定の URL から zip アーカイブをダウンロード」などです。
できます」または「特定の Maven アーティファクトをフェッチして、
java_import
ターゲット」または単に「ローカル ディレクトリのシンボリック リンク」を指定します。すべてのリポジトリは
defined: 適切な数の引数を指定してリポジトリ ルールを呼び出します。
書き込む方法の詳細については、リポジトリ ルールをご覧ください。 ルールを独自に作成することもできます。
これまでで最も一般的なリポジトリ ルールは、
http_archive
- アーカイブをダウンロードします。
URL から抽出して
local_repository
。これは Pod の
ローカルディレクトリに移動します。
リポジトリを取得する
関連付けられたリポジトリを実行して、ローカル ディスク上でリポジトリを使用できるようにするアクション 追加します。ワークスペースで定義されたリポジトリがローカル ディスクで使用できない 呼び出します。
通常、Bazel は、必要なときのみリポジトリを取得します。 リポジトリがまだ取得されていないことを示しています。リポジトリがすでに取得されている場合 Bazel は定義が変更された場合にのみ再取得します。
ディレクトリ レイアウト
取得されたリポジトリは、プロジェクトのサブディレクトリ external
にあります。
出力ベースです。
次のコマンドを実行すると、
正規名 canonical_name
:
ls $(bazel info output_base)/external/ canonical_name
Bzlmod による外部依存関係の管理
新しい外部依存関係サブシステムである Bzlmod がリポジトリで直接機能しない あります。その代わりに、モジュールから依存関係グラフを作成し、 extensions を表示し、それに応じてリポジトリを定義します。
Bazel モジュールは、複数のモジュールを接続できる Bazel プロジェクトです。
各バージョンでは、依存関係にある他のモジュールに関するメタデータが
オンにします。モジュールでは、リポジトリのルート、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")
モジュールは、その直接的な依存関係のみをリストする必要があります。これは Bzlmod が
Bazel レジストリ - デフォルトは Bazel Central
レジストリ。レジストリは、
MODULE.bazel
ファイル。これにより、Bazel はシステム全体を検出できます。
バージョン解決前の推移的依存関係グラフ
バージョンの解決(モジュールごとに 1 つのバージョンが選択される)の後、
Bazel はレジストリを再度参照して各モジュールのリポジトリを定義する方法を確認する
(ほとんどの場合、http_archive
を使用します)。
モジュールでは、タグと呼ばれるカスタマイズされたデータを指定することもできます。 モジュールの解決後にモジュール拡張機能で使用 追加のリポジトリを定義しますこれらの拡張機能には、リポジトリに ルールにより、ファイル I/O や送信ネットワークなどのアクションを できます。特に、Bazel が他のパッケージとやり取りできるようにする Bazel で構築された依存関係グラフも考慮します。 説明します。
Bzlmod の外部リンク
- bazelbuild/examples での Bzlmod の使用例
- Bazel 外部依存関係の見直し (元の Bzlmod 設計ドキュメント)
- Bzlmod に関する BazelCon 2021 の講演
- Bzlmod に関する Bazel Community Day のトーク
WORKSPACE
でリポジトリを定義する
これまでは、Google Cloud コンソールでリポジトリを定義することにより、外部依存関係を管理できていました。
WORKSPACE
(または WORKSPACE.bazel
)ファイル。このファイルの構文は、
BUILD
ファイル(ビルドルールの代わりに Repo ルールを使用する)。
次のスニペットは、http_archive
リポジトリ ルールを使用する例です。
WORKSPACE
ファイル:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "foo",
urls = ["https://example.com/foo.zip"],
sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)
スニペットでは、正規名が foo
のリポジトリが定義されています。WORKSPACE
デフォルトでは、リポジトリの正規名が、
コピーされます。
利用可能な関数の一覧
WORKSPACE
ファイル。
WORKSPACE
システムの欠点
WORKSPACE
システム導入以来、
多くの課題があります
- Bazel では依存関係の
WORKSPACE
ファイルが評価されないため、すべての依存関係が 推移的依存関係は、メインのプロジェクトのWORKSPACE
ファイルで定義する必要があります。 リポジトリのほか、ディレクトリにある依存関係も存在します。 - これを回避するために、プロジェクトでは「deps.bzl」パターンである
複数のリポジトリを定義するマクロを定義し、ユーザーに
WORKSPACE
ファイルでこのマクロを呼び出します。- これには独自の問題があります。マクロは他の
.bzl
ファイルをload
することができないため、 依存関係を定義する必要があります。 「deps」マクロを使用するか、ユーザーに レイヤ化された「deps」マクロ。 - Bazel は、
WORKSPACE
ファイルを順番に評価します。また 依存関係を指定するには、http_archive
で URL を指定します。 バージョン情報。つまり、データ アナリストがパフォーマンスを ダイヤモンド依存関係の場合のバージョン解決(A
はB
、C
B
とC
は、D
の異なるバージョンに依存しています)。
- これには独自の問題があります。マクロは他の
WORKSPACE の欠点により、Bzlmod が従来の WORKSPACE システム(今後の Bazel リリース)。詳しくは、Bzlmod の移行 ガイドをご覧ください。