💚? Bazel ユーザーアンケートにご記入ください。Bazel の改善に役立てさせていただきます。https://bazel.build/survey 💚?

このページは Cloud Translation API によって翻訳されました。

可視性
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

問題を報告するソースを表示 ナイトリー · 8.2 · 8.1 · 8.0 · 7.6 · 7.5

このページでは、Bazel の 2 つの可視性システム（ターゲット可視性と読み込み可視性）について説明します。

どちらの公開設定も、他のデベロッパーがライブラリのパブリック API とその実装の詳細を区別し、ワークスペースの増大に応じて構造を適用するのに役立ちます。公開 API の非推奨化時に公開設定を使用して、既存のユーザーを許可し、新しいユーザーを拒否することもできます。

ターゲットの公開設定

ターゲットの公開設定では、ターゲットに依存するユーザー（deps などの属性内でターゲットのラベルを使用するユーザー）を制御します。ターゲットが依存関係のいずれかの公開設定に違反している場合、分析フェーズでビルドに失敗します。

通常、ターゲット A は、同じロケーションにある場合、または A が B のロケーションへの可視性を許可している場合に、ターゲット B に表示されます。記号マクロがない場合、「ロケーション」という用語は「パッケージ」に簡略化できます。記号マクロの詳細については、下記をご覧ください。

公開設定は、許可されたパッケージを一覧表示することで指定します。パッケージを許可しても、そのサブパッケージも許可されるとは限りません。パッケージとサブパッケージの詳細については、コンセプトと用語をご覧ください。

プロトタイピングでは、フラグ --check_visibility=false を設定することで、ターゲットの公開設定の適用を無効にできます。送信されたコードで本番環境で使用する場合、これは行わないでください。

公開設定を制御する主な方法は、ルールの visibility 属性を使用することです。次のサブセクションでは、属性の形式、さまざまなターゲットに適用する方法、可視性システムとシンボリックマクロの相互作用について説明します。

公開設定の仕様

すべてのルールターゲットには、ラベルのリストを受け取る visibility 属性があります。各ラベルは次のいずれかの形式になります。最後の形式を除き、これらは実際のターゲットに対応していない構文プレースホルダにすぎません。

"//visibility:public": すべてのパッケージへのアクセス権を付与します。
"//visibility:private": 追加のアクセス権は付与されません。このロケーションのパッケージ内のターゲットのみ、このターゲットを使用できます。
"//foo/bar:__pkg__": //foo/bar へのアクセス権を付与します（サブパッケージにはアクセス権を付与しません）。
"//foo/bar:__subpackages__": //foo/bar とその直接および間接のサブパッケージへのアクセス権を付与します。
"//some_pkg:my_package_group": 指定された package_group に含まれるすべてのパッケージへのアクセスを許可します。
- パッケージグループでは、パッケージの指定に異なる構文が使用されます。パッケージグループ内では、フォーム "//foo/bar:__pkg__" と "//foo/bar:__subpackages__" はそれぞれ "//foo/bar" と "//foo/bar/..." に置き換えられます。同様に、"//visibility:public" と "//visibility:private" は単なる "public" と "private" です。

たとえば、//some/package:mytarget の visibility が [":__subpackages__", "//tests:__pkg__"] に設定されている場合、//some/package/... ソースツリーの一部である任意のターゲットと、//tests/BUILD で宣言されたターゲットで使用できますが、//tests/integration/BUILD で定義されたターゲットでは使用できません。

ベストプラクティス: 複数のターゲットを同じパッケージセットに表示するには、各ターゲットの visibility 属性でリストを繰り返すのではなく、package_group を使用します。これにより、可読性が向上し、リストの同期がずれるのを防ぐことができます。

ベストプラクティス: 別のチームのプロジェクトに公開権限を付与する場合は、__pkg__ ではなく __subpackages__ を使用することをおすすめします。プロジェクトの進化や新しいサブパッケージの追加に伴う、不要な公開権限の変更を回避できます。

ルールのターゲットの公開設定

ルールターゲットの公開設定は、その visibility 属性（指定されていない場合は適切なデフォルト）を取得し、ターゲットが宣言されたロケーションを追加することで決まります。シンボリックマクロで宣言されていないターゲットの場合、パッケージで default_visibility が指定されている場合は、このデフォルトが使用されます。他のすべてのパッケージとシンボリックマクロで宣言されたターゲットの場合、デフォルトは ["//visibility:private"] です。

# //mypkg/BUILD

package(default_visibility = ["//friend:__pkg__"])

cc_library(
    name = "t1",
    ...
    # No visibility explicitly specified.
    # Effective visibility is ["//friend:__pkg__", "//mypkg:__pkg__"].
    # If no default_visibility were given in package(...), the visibility would
    # instead default to ["//visibility:private"], and the effective visibility
    # would be ["//mypkg:__pkg__"].
)

cc_library(
    name = "t2",
    ...
    visibility = [":clients"],
    # Effective visibility is ["//mypkg:clients, "//mypkg:__pkg__"], which will
    # expand to ["//another_friend:__subpackages__", "//mypkg:__pkg__"].
)

cc_library(
    name = "t3",
    ...
    visibility = ["//visibility:private"],
    # Effective visibility is ["//mypkg:__pkg__"]
)

package_group(
    name = "clients",
    packages = ["//another_friend/..."],
)

ベストプラクティス: default_visibility を公開に設定しないでください。プロトタイピングや小規模なコードベースでは便利ですが、コードベースのサイズが大きくなるにつれて、誤って公開ターゲットを作成するリスクが高まります。パッケージのパブリックインターフェースの一部であるターゲットを明示的に指定することをおすすめします。

生成されたファイルターゲットの公開設定

生成されたファイルターゲットの公開設定は、そのターゲットを生成するルールターゲットと同じです。

# //mypkg/BUILD

java_binary(
    name = "foo",
    ...
    visibility = ["//friend:__pkg__"],
)

# //friend/BUILD

some_rule(
    name = "bar",
    deps = [
        # Allowed directly by visibility of foo.
        "//mypkg:foo",
        # Also allowed. The java_binary's "_deploy.jar" implicit output file
        # target the same visibility as the rule target itself.
        "//mypkg:foo_deploy.jar",
    ]
    ...
)

ソースファイルターゲットの公開設定

ソースファイルターゲットは、exports_files を使用して明示的に宣言することも、ルールのラベル属性でファイル名を参照して暗黙的に作成することもできます（シンボリックマクロの外部）。ルールターゲットと同様に、exports_files の呼び出しの場所、または入力ファイルを参照した BUILD ファイルは、常にファイルの公開設定に自動的に追加されます。

exports_files で宣言されたファイルの可視性は、その関数の visibility パラメータで設定できます。このパラメータを指定しない場合、公開設定は公開されます。

exports_files の呼び出しに表示されないファイルの場合、可視性はフラグ --incompatible_no_implicit_file_export の値によって異なります。

フラグが true の場合、公開設定は非公開です。
それ以外の場合は、従来の動作が適用されます。公開設定は BUILD ファイルの default_visibility と同じになります。デフォルトの公開設定が指定されていない場合は非公開になります。

以前の動作に依存しないでください。ソースファイルターゲットで非公開以外の公開設定が必要な場合は、必ず exports_files 宣言を記述します。

ベストプラクティス: 可能であれば、ソースファイルではなくルールターゲットを公開します。たとえば、.java ファイルで exports_files を呼び出すのではなく、非公開以外の java_library ターゲットでファイルをラップします。通常、ルールターゲットは、同じパッケージにあるソースファイルのみを直接参照する必要があります。

例

ファイル //frobber/data/BUILD:

exports_files(["readme.txt"])

ファイル //frobber/bin/BUILD:

cc_binary(
  name = "my-program",
  data = ["//frobber/data:readme.txt"],
)

設定の公開設定

これまで、Bazel では select() のキーで参照される config_setting ターゲットの可視性が適用されていませんでした。この以前の動作を削除するフラグは 2 つあります。

--incompatible_enforce_config_setting_visibility を使用すると、これらのターゲットの公開設定の確認が有効になります。また、移行を支援するために、visibility を指定しなかった config_setting は、（パッケージレベルの default_visibility に関係なく）公開と見なされます。
--incompatible_config_setting_private_default_visibility を使用すると、visibility を指定しなかった config_setting は、他のルールターゲットと同様に、パッケージの default_visibility を尊重し、非公開の公開設定にフォールバックします。--incompatible_enforce_config_setting_visibility が設定されていない場合、これは no-op です。

以前の動作に依存しないでください。現在のパッケージの外部で使用することを目的とした config_setting には、パッケージで適切な default_visibility がまだ指定されていない場合は、明示的な visibility が必要です。

パッケージグループターゲットの公開設定

package_group ターゲットに visibility 属性はありません。常に一般公開されます。

暗黙的な依存関係の可視性

一部のルールには暗黙的な依存関係があります。これは、BUILD ファイルに明記されていないものの、そのルールのすべてのインスタンスに固有の依存関係です。たとえば、cc_library ルールでは、各ルールターゲットから C++ コンパイラを表す実行可能ターゲットへの暗黙的な依存関係が作成されます。

このような暗黙的な依存関係の公開設定は、ルール（またはアスペクト）が定義されている .bzl ファイルを含むパッケージに対してチェックされます。この例では、C++ コンパイラは、cc_library ルールの定義と同じパッケージ内にある限り、非公開にできます。フォールバックとして、暗黙的な依存関係が定義から検出されない場合は、cc_library ターゲットに対してチェックされます。

ルールの使用を特定のパッケージに制限する場合は、代わりに読み込みの可視性を使用します。

可視性とシンボリックマクロ

このセクションでは、可視性システムがシンボリックマクロとやり取りする方法について説明します。

記号マクロ内のロケーション

公開設定システムの重要な詳細は、宣言の場所を決定する方法です。シンボリックマクロで宣言されていないターゲットの場合、ロケーションはターゲットが存在するパッケージ（BUILD ファイルのパッケージ）です。ただし、シンボリックマクロで作成されたターゲットの場合、場所は、マクロの定義（my_macro = macro(...) ステートメント）が存在する .bzl ファイルを含むパッケージです。複数のネストされたターゲット内にターゲットが作成された場合、常に最も内側のシンボリックマクロの定義が使用されます。

特定の依存関係の可視性に対してチェックする場所を決定するためにも、同じシステムが使用されます。使用ターゲットがマクロ内で作成された場合、使用ターゲットが存在するパッケージではなく、最も内側のマクロの定義が検査されます。

つまり、コードが同じパッケージで定義されているすべてのマクロは、自動的に相互に「フレンド」になります。//lib:defs.bzl で定義されたマクロによって直接作成されたターゲットは、マクロが実際にインスタンス化されたパッケージに関係なく、//lib で定義された他のマクロから参照できます。同様に、//lib/BUILD とそのレガシーマクロで直接宣言されたターゲットを参照し、参照されることができます。逆に、同じパッケージに存在するターゲットでも、少なくとも 1 つがシンボリックマクロによって作成されている場合、互いを見通せるとは限りません。

シンボリックマクロの実装関数内では、visibility パラメータには、マクロが呼び出された場所を追加した後のマクロの visibility 属性の有効な値が含まれます。マクロがターゲットのいずれかを呼び出し元にエクスポートする標準的な方法は、some_rule(..., visibility = visibility) のように、この値をターゲットの宣言に転送することです。この属性を省略したターゲットは、呼び出し元がマクロ定義と同じパッケージに存在しない限り、マクロの呼び出し元には表示されません。この動作は、サブマクロへのネストされた呼び出しのチェーンがそれぞれ visibility = visibility を渡し、内部マクロのエクスポートされたターゲットを各レベルの呼び出し元に再エクスポートするという意味において、コンポーズされます。このとき、マクロの実装の詳細は公開されません。

サブマクロに権限を委任する

公開設定モデルには、マクロが権限をサブマクロに委任できる特別な機能があります。これは、マクロの分解と合成に重要です。

別のパッケージのルール some_library を使用して依存関係エッジを作成するマクロ my_macro があるとします。

# //macro/defs.bzl
load("//lib:defs.bzl", "some_library")

def _impl(name, visibility, ...):
    ...
    native.genrule(
        name = name + "_dependency"
        ...
    )
    some_library(
        name = name + "_consumer",
        deps = [name + "_dependency"],
        ...
    )

my_macro = macro(implementation = _impl, ...)

# //pkg/BUILD

load("//macro:defs.bzl", "my_macro")

my_macro(name = "foo", ...)

//pkg:foo_dependency ターゲットに visibility が指定されていないため、//macro 内でのみ表示されますが、これは使用ターゲットでは問題ありません。//lib の作成者が some_library をリファクタリングして、代わりにマクロを使用して実装した場合はどうなりますか？

# //lib:defs.bzl

def _impl(name, visibility, deps, ...):
    some_rule(
        # Main target, exported.
        name = name,
        visibility = visibility,
        deps = deps,
        ...)

some_library = macro(implementation = _impl, ...)

この変更により、//pkg:foo_consumer の場所が //macro から //lib に変更されたため、//pkg:foo_dependency の使用は依存関係の公開設定に違反しています。my_macro の作成者は、この実装の詳細を回避するためだけに、visibility = ["//lib"] を依存関係の宣言に渡すことは期待できません。

このため、ターゲットの依存関係がターゲットを宣言したマクロの属性値でもある場合、依存関係の公開設定は、使用しているターゲットの場所ではなく、マクロの場所と照合されます。

この例では、//pkg:foo_consumer が //pkg:foo_dependency を参照できるかどうかを検証するために、//pkg:foo_dependency が my_macro 内の some_library への呼び出しにも入力として渡されていることを確認します。代わりに、この呼び出しの場所である //macro に対して依存関係の可視性を確認します。

ターゲットまたはマクロ宣言が、ラベル型の属性のいずれかで依存関係のラベルを取得する別のシンボリックマクロ内にある限り、このプロセスは再帰的に繰り返すことができます。

ファイナライザ

ルールファイナライザ（finalizer = True を含むシンボリックマクロ）で宣言されたターゲットは、通常のシンボリックマクロの可視性ルールに従ってターゲットを表示できるだけでなく、ファイナライザターゲットのパッケージに表示されるすべてのターゲットも表示できます。

つまり、native.existing_rules() ベースのレガシーマクロをファイナライザに移行しても、ファイナライザによって宣言されたターゲットは、古い依存関係を認識できます。

ファイナライザが native.existing_rules() を使用してイントロスペクトできるターゲットを定義できますが、可視性システムで依存関係として使用することはできません。たとえば、マクロで定義されたターゲットが、そのパッケージまたはファイナライザマクロの定義に表示されず、ファイナライザに委任されていない場合、ファイナライザはそのようなターゲットを認識できません。ただし、native.existing_rules() ベースの従来のマクロでも、このようなターゲットを検出できません。

読み込みの可視性

読み込みの公開設定は、.bzl ファイルを現在のパッケージ外の他の BUILD ファイルまたは .bzl ファイルから読み込むことができるかどうかを制御します。

ターゲットビジュアリゼーションがターゲットによってカプセル化されたソースコードを保護するのと同様に、読み込みビジュアリゼーションは .bzl ファイルによってカプセル化されたビルドロジックを保護します。たとえば、BUILD ファイルの作成者は、繰り返しの多いターゲット宣言を .bzl ファイルのマクロに分割できます。ロードの可視性の保護がないと、同じワークスペース内の他の共同編集者によってマクロが再利用されるため、マクロを変更すると他のチームのビルドが破損する可能性があります。

.bzl ファイルには、対応するソースファイルターゲットが存在する場合と存在しない場合もあります。ロードの公開設定とターゲットの公開設定が一致するとは限りません。つまり、同じ BUILD ファイルで .bzl ファイルを読み込めるものの、filegroup の srcs にリストされない場合があります。その逆も同様です。これにより、ドキュメントの生成やテストなど、.bzl ファイルをソースコードとして使用するルールで問題が発生することがあります。

プロトタイピングの場合は、--check_bzl_visibility=false を設定することで、読み込みの可視性の適用を無効にできます。--check_visibility=false と同様に、送信されたコードでは行わないでください。

負荷の可視性は、Bazel 6.0 以降で利用できます。

読み込みの公開設定を宣言する

.bzl ファイルの読み込みの公開設定を設定するには、ファイル内から visibility() 関数を呼び出します。visibility() の引数は、package_group の packages 属性と同様に、パッケージ仕様のリストです。ただし、visibility() は負のパッケージ仕様を受け入れません。

visibility() の呼び出しは、ファイルごとに 1 回だけ、最上位レベル（関数内ではない）で行う必要があります。理想的には、load() ステートメントの直後に行います。

ターゲットの公開設定とは異なり、デフォルトの読み込みの公開設定は常に公開されます。visibility() を呼び出さないファイルは、ワークスペースのどこからでも常に読み込むことができます。パッケージの外部で使用することを特に意図していない新しい .bzl ファイルの先頭に visibility("private") を追加することをおすすめします。

例

# //mylib/internal_defs.bzl

# Available to subpackages and to mylib's tests.
visibility(["//mylib/...", "//tests/mylib/..."])

def helper(...):
    ...

# //mylib/rules.bzl

load(":internal_defs.bzl", "helper")
# Set visibility explicitly, even though public is the default.
# Note the [] can be omitted when there's only one entry.
visibility("public")

myrule = rule(
    ...
)

# //someclient/BUILD

load("//mylib:rules.bzl", "myrule")          # ok
load("//mylib:internal_defs.bzl", "helper")  # error

...

読み込みの可視化のベストプラクティス

このセクションでは、負荷可視性宣言を管理するためのヒントについて説明します。

因数分解の公開設定

複数の .bzl ファイルに同じ公開設定を適用する場合は、パッケージ仕様を共通のリストにまとめると便利です。次に例を示します。

# //mylib/internal_defs.bzl

visibility("private")

clients = [
    "//foo",
    "//bar/baz/...",
    ...
]

# //mylib/feature_A.bzl

load(":internal_defs.bzl", "clients")
visibility(clients)

...

# //mylib/feature_B.bzl

load(":internal_defs.bzl", "clients")
visibility(clients)

...

これにより、さまざまな .bzl ファイルの可視性が誤ってずれるのを防ぐことができます。また、clients リストが大きい場合でも読みやすくなります。

可視性の合成

複数の小さな許可リストで構成される許可リストに .bzl ファイルを表示する必要がある場合があります。これは、package_group が includes 属性を介して他の package_group を組み込む方法に似ています。

広く使用されているマクロを非推奨にするとします。既存のユーザーと、自分のチームが所有するパッケージにのみ表示したい場合。次のように記述します。

# //mylib/macros.bzl

load(":internal_defs.bzl", "our_packages")
load("//some_big_client:defs.bzl", "their_remaining_uses")

# List concatenation. Duplicates are fine.
visibility(our_packages + their_remaining_uses)

パッケージグループによる重複除去

ターゲットビジュアリゼーションとは異なり、読み込みビジュアリゼーションを package_group で定義することはできません。ターゲットの公開設定と読み込みの公開設定の両方で同じ許可リストを再利用する場合は、パッケージ仕様のリストを .bzl ファイルに移動することをおすすめします。このファイルでは、両方の宣言でリストを参照できます。上記の公開設定の分類の例を基に、次のように記述できます。

# //mylib/BUILD

load(":internal_defs", "clients")

package_group(
    name = "my_pkg_grp",
    packages = clients,
)

これは、リストにネガティブなパッケージ仕様が含まれていない場合にのみ機能します。

個々の記号を保護する

名前がアンダースコアで始まる Starlark シンボルは、別のファイルから読み込むことはできません。これにより、非公開のシンボルを簡単に作成できますが、これらのシンボルを限定された信頼できるファイルセットと共有することはできません。一方、読み込みの公開設定では、他のパッケージが .bzl file を参照できるかどうかを制御できますが、アンダースコアが付いていないシンボルが読み込まれないようにすることはできません。

幸い、この 2 つの機能を組み合わせてきめ細かい制御を行うことができます。

# //mylib/internal_defs.bzl

# Can't be public, because internal_helper shouldn't be exposed to the world.
visibility("private")

# Can't be underscore-prefixed, because this is
# needed by other .bzl files in mylib.
def internal_helper(...):
    ...

def public_util(...):
    ...

# //mylib/defs.bzl

load(":internal_defs", "internal_helper", _public_util="public_util")
visibility("public")

# internal_helper, as a loaded symbol, is available for use in this file but
# can't be imported by clients who load this file.
...

# Re-export public_util from this file by assigning it to a global variable.
# We needed to import it under a different name ("_public_util") in order for
# this assignment to be legal.
public_util = _public_util

bzl-visibility Buildifier lint

Buildifier lint があり、ユーザーが internal または private という名前のディレクトリからファイルを読み込むときに、そのユーザーのファイルがそのディレクトリの親の下にない場合に警告が表示されます。この lint は読み込みの可視性機能より前のものであり、.bzl ファイルで可視性を宣言するワークスペースでは不要です。