外部依存関係の概要

<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 つのシステムについて詳しく見ていきましょう

コンセプト

リポジトリ

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

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 システム導入以来、 多くの課題があります

  • Bazel では依存関係の WORKSPACE ファイルが評価されないため、すべての依存関係が 推移的依存関係は、メインのプロジェクトの WORKSPACE ファイルで定義する必要があります。 リポジトリのほか、ディレクトリにある依存関係も存在します。
  • これを回避するために、プロジェクトでは「deps.bzl」パターンである 複数のリポジトリを定義するマクロを定義し、ユーザーに WORKSPACE ファイルでこのマクロを呼び出します。
    • これには独自の問題があります。マクロは他の .bzl ファイルを load することができないため、 依存関係を定義する必要があります。 「deps」マクロを使用するか、ユーザーに レイヤ化された「deps」マクロ。
    • Bazel は、WORKSPACE ファイルを順番に評価します。また 依存関係を指定するには、http_archive で URL を指定します。 バージョン情報。つまり、データ アナリストがパフォーマンスを ダイヤモンド依存関係の場合のバージョン解決(ABCBC は、D の異なるバージョンに依存しています)。

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