外部依存関係の概要

<ph type="x-smartling-placeholder"></ph> 問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel は、外部依存関係、使用するソースファイル（テキストとバイナリの両方）をサポートしています。 自動的に作成されます。たとえば、 GitHub リポジトリ、Maven アーティファクト、またはローカルのディレクトリでホストされている 現在のワークスペースから移動することはできません。

Bazel 6.0 以降では、Bazel で外部依存関係を管理する方法が 2 つあります。 従来のリポジトリを中心とした WORKSPACE システム モジュールに焦点を当てた新しい MODULE.bazel システム（コードネーム Bzlmod、 フラグ --enable_bzlmod で有効にします）。この 2 つのシステムは ただし、将来的に Bazel で WORKSPACE システムを置き換えるのは Bzlmod です。 移行方法については、Bzlmod 移行ガイドをご覧ください。 移行できます。

このドキュメントでは、外部依存関係の管理に関するコンセプトについて説明します。 2 つのシステムについて詳しく見ていきましょう

コンセプト

リポジトリ

ルートに境界マーカー ファイルがあり、ソースを含むディレクトリ ツリー Bazel ビルドで使用できるファイルです。多くの場合、リポのために短縮されます。

リポジトリ境界マーカー ファイルは MODULE.bazel にできます（このリポジトリが Bazel モジュールを表します）、REPO.bazel（下記を参照）、または レガシー コンテキスト、WORKSPACE または WORKSPACE.bazel。任意のリポジトリ境界マーカー ファイル リポジトリの境界を示します。そのようなファイルを 1 つの環境に されます。

メイン リポジトリ

現在の 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 は定義が変更された場合にのみ再取得します。

fetch コマンドを使用すると、リポジトリのプリフェッチを開始できます。 またはすべてのビルドを実行するために必要なすべてのリポジトリにアタッチできます。この機能 --nofetch オプションを使用してオフライン ビルドを有効にします。

--fetch オプションは、ネットワーク アクセスの管理に使用されます。デフォルト値は true です。 ただし、false（--nofetch）に設定すると、コマンドはキャッシュに保存された 存在しない場合は、コマンドの結果に 失敗します。

詳細については、取得オプションをご覧ください。 取得の制御に関する情報をご覧ください。

ディレクトリ レイアウト

取得されたリポジトリは、プロジェクトのサブディレクトリ external にあります。 出力ベースです。

次のコマンドを実行すると、 正規名 canonical_name:

ls $(bazel info output_base)/external/ canonical_name

REPO.bazel ファイル

REPO.bazel ファイルは、ディレクトリ ツリーの最上位をマークするために使用されます。 構成します。リポジトリとして機能するものを含める必要はありません 境界ファイル一般的な属性の指定にも使用できます。 リポジトリ内のすべてのビルド ターゲットに対して適用されます。

REPO.bazel ファイルの構文は BUILD ファイルと似ていますが、 load ステートメントはサポートされていますが、単一の関数 repo() のみを使用できます。 できます。repo() は package() と同じ引数を取ります。 BUILD ファイル内の関数一方、package() パッケージ repo() 内のすべてのビルド ターゲットに共通の属性を指定します。 同様に、リポジトリ内のすべてのビルド ターゲットに対してこの処理を行います。

たとえば、次のコマンドを使用して、リポジトリ内のすべてのターゲットに共通のライセンスを指定できます。 次の REPO.bazel ファイルがあります。

repo(
    default_package_metadata = ["//:my_license"],
)

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 で構築された依存関係グラフも考慮します。 説明します。

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、CB と C は、D の異なるバージョンに依存しています）。

WORKSPACE の欠点により、Bzlmod が従来の WORKSPACE システム（今後の Bazel リリース）。詳しくは、Bzlmod の移行 ガイドをご覧ください。