このページでは、Bazel の 2 つの可視性システム(ターゲット可視性とロード可視性)について説明します。
どちらの公開設定も、他のデベロッパーがライブラリの公開 API とその実装の詳細を区別し、ワークスペースが拡大しても構造を適用するうえで役立ちます。また、公開 API を非推奨にする際に可視性を使用して、現在のユーザーは許可し、新規ユーザーは拒否できます。
ターゲットの表示
ターゲットの公開設定は、ターゲットに依存するユーザー(つまり、deps
などの属性内でターゲットのラベルを使用できるユーザー)を制御します。
ターゲット A
は、同じパッケージ内にある場合、または A
が B
のパッケージの公開設定を許可している場合、ターゲット B
から認識できます。このように、パッケージはアクセスを許可するかどうかを決定するための粒度単位となります。B
が 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
を使用します。これにより、読みやすさが向上し、リストが同期しなくなることを防ぎます。
ルール ターゲットの表示設定
ルール ターゲットの表示設定は次のとおりです。
visibility
属性の値(設定されている場合)。ターゲットの
BUILD
ファイル内のpackage
ステートメントのdefault_visibility
引数の値(そのような宣言が存在する場合)。それ以外の場合は、//visibility:private
.
ベスト プラクティス: default_visibility
は公開に設定しないでください。プロトタイピングや小規模なコードベースには便利ですが、コードベースが大きくなるにつれて、誤って一般公開ターゲットを作成するリスクが高くなります。パッケージの公開インターフェースの一部であるターゲットを明示的に指定することをおすすめします。
例
ファイル //frobber/bin/BUILD
:
# This target is visible to everyone
cc_binary(
name = "executable",
visibility = ["//visibility:public"],
deps = [":library"],
)
# This target is visible only to targets declared in the same package
cc_library(
name = "library",
# No visibility -- defaults to private since no
# package(default_visibility = ...) was used.
)
# This target is visible to targets in package //object and //noun
cc_library(
name = "subject",
visibility = [
"//noun:__pkg__",
"//object:__pkg__",
],
)
# See package group "//frobber:friends" (below) for who can
# access this target.
cc_library(
name = "thingy",
visibility = ["//frobber:friends"],
)
ファイル //frobber/BUILD
:
# This is the package group declaration to which target
# //frobber/bin:thingy refers.
#
# Our friends are packages //frobber, //fribber and any
# subpackage of //fribber.
package_group(
name = "friends",
packages = [
"//fribber/...",
"//frobber",
],
)
生成されたファイルのターゲットの公開設定
生成されたファイル ターゲットは、その生成元のルール ターゲットと同じ可視性になります。
ソースファイルのターゲットの公開設定
ソースファイルのターゲットの公開設定を明示的に設定するには、exports_files
を呼び出します。visibility
引数が exports_files
に渡されない場合、可視性はパブリックになります。exports_files
を使用して、生成されたファイルの公開設定をオーバーライドすることはできません。
exports_files
の呼び出しで表示されないソースファイル ターゲットの場合、可視性はフラグ --incompatible_no_implicit_file_export
の値によって異なります。
このフラグが設定されている場合、公開設定は非公開になります。
それ以外の場合は、従来の動作が適用されます。公開設定は
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
が設定されていない場合、処理は行われません。
従来の動作に依存しないようにします。現在のパッケージの外部で使用する config_setting
は、パッケージが適切な default_visibility
をまだ指定していない場合に、明示的な visibility
を含める必要があります。
パッケージ グループのターゲットの公開設定
package_group
ターゲットに visibility
属性がありません。常に一般公開されます。
暗黙的な依存関係の可視性
一部のルールには暗黙的な依存関係があります。これは、BUILD
ファイルに記述されていないものの、そのルールのすべてのインスタンスに固有の依存関係です。たとえば、cc_library
ルールによって、各ルール ターゲットから C++ コンパイラを表す実行可能ターゲットへの暗黙的な依存関係が作成されることがあります。
現在、可視性の目的で、これらの暗黙的な依存関係は他の依存関係と同様に扱われます。つまり、依存するターゲット(C++ コンパイラなど)はルールのすべてのインスタンスから参照できる必要があります。実際には、これは通常、ターゲットが一般公開されている必要があることを意味します。
この動作を変更するには、--incompatible_visibility_private_attributes_at_definition
を設定します。有効にすると、問題のターゲットは、暗黙的な依存関係を宣言しているルールからのみ認識できます。つまり、ルールが定義されている .bzl
ファイルを含むパッケージから参照できる必要があります。この例では、C++ コンパイラが cc_library
ルールの定義と同じパッケージ内に存在する限り、非公開にできます。
読み込みの可視性
読み込みの公開設定は、.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
ファイルによって可視性を宣言するワークスペースでは必要ありません。