এই পৃষ্ঠাটি Bazel এর দুটি দৃশ্যমানতা সিস্টেমকে কভার করে: লক্ষ্য দৃশ্যমানতা এবং লোড দৃশ্যমানতা ।
উভয় ধরণের দৃশ্যমানতা অন্যান্য বিকাশকারীদের আপনার লাইব্রেরির সর্বজনীন API এবং এর বাস্তবায়নের বিবরণের মধ্যে পার্থক্য করতে সহায়তা করে এবং আপনার কর্মক্ষেত্র বৃদ্ধির সাথে সাথে কাঠামো প্রয়োগ করতে সহায়তা করে। নতুনকে অস্বীকার করার সময় বর্তমান ব্যবহারকারীদের মঞ্জুরি দেওয়ার জন্য আপনি একটি সর্বজনীন API বর্জন করার সময় দৃশ্যমানতা ব্যবহার করতে পারেন।
লক্ষ্য দৃশ্যমানতা
টার্গেট ভিজিবিলিটি নিয়ন্ত্রণ করে কে আপনার টার্গেটের উপর নির্ভর করতে পারে — অর্থাৎ, যারা deps
মতো অ্যাট্রিবিউটের ভিতরে আপনার টার্গেটের লেবেল ব্যবহার করতে পারে।
একটি লক্ষ্য A
একটি লক্ষ্য B
এর কাছে দৃশ্যমান হয় যদি তারা একই প্যাকেজে থাকে বা A
যদি 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__"
bar:__subpackages__" যথাক্রমে"//foo/bar"
এবং"//foo/bar/..."
দ্বারা প্রতিস্থাপিত হয়। একইভাবে,"//visibility:public"
এবং"//visibility:private"
শুধুমাত্র"public"
এবং"private"
।
- প্যাকেজ গ্রুপগুলি প্যাকেজ নির্দিষ্ট করার জন্য একটি ভিন্ন সিনট্যাক্স ব্যবহার করে। একটি প্যাকেজ গ্রুপের মধ্যে, ফর্ম
উদাহরণস্বরূপ, যদি //some/package:mytarget
এর visibility
[":__subpackages__", "//tests:__pkg__"]
সেট করা থাকে, তাহলে এটি //some/package/...
-এর অংশ এমন যেকোনো লক্ষ্য দ্বারা ব্যবহার করা যেতে পারে। //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
কল করে একটি সোর্স ফাইল টার্গেটের দৃশ্যমানতা স্পষ্টভাবে সেট করতে পারেন। যখন exports_files
কোনো visibility
যুক্তি পাস করা হয় না, তখন এটি দৃশ্যমানতাকে সর্বজনীন করে তোলে। exports_files
একটি জেনারেট করা ফাইলের দৃশ্যমানতা ওভাররাইড করতে ব্যবহার করা যাবে না।
উৎস ফাইল টার্গেটের জন্য exports_files
কলে উপস্থিত হয় না, দৃশ্যমানতা পতাকার মানের উপর নির্ভর করে --incompatible_no_implicit_file_export
:
পতাকা সেট করা থাকলে, দৃশ্যমানতা ব্যক্তিগত।
অন্যথায়, লিগ্যাসি আচরণ প্রযোজ্য: দৃশ্যমানতা
BUILD
ফাইলেরdefault_visibility
মতই, অথবা যদি ডিফল্ট দৃশ্যমানতা নির্দিষ্ট করা না থাকে তাহলে ব্যক্তিগত।
উত্তরাধিকার আচরণের উপর নির্ভর করা এড়িয়ে চলুন। যখনই একটি উৎস ফাইল টার্গেটের জন্য অ-ব্যক্তিগত দৃশ্যমানতার প্রয়োজন হয় তখন সর্বদা একটি exports_files
ঘোষণা লিখুন।
সর্বোত্তম অনুশীলন: যখন সম্ভব, উত্স ফাইলের পরিবর্তে একটি নিয়ম লক্ষ্য প্রকাশ করতে পছন্দ করুন৷ উদাহরণস্বরূপ, একটি exports_files
ফাইলে .java
কল করার পরিবর্তে, ফাইলটিকে একটি নন-প্রাইভেট java_library
টার্গেটে মোড়ানো। সাধারনত, রুল টার্গেট শুধুমাত্র একই প্যাকেজে থাকা সোর্স ফাইলগুলিকে সরাসরি উল্লেখ করা উচিত।
উদাহরণ
ফাইল //frobber/data/BUILD
:
exports_files(["readme.txt"])
ফাইল //frobber/bin/BUILD
:
cc_binary(
name = "my-program",
data = ["//frobber/data:readme.txt"],
)
কনফিগ সেটিং দৃশ্যমানতা
ঐতিহাসিকভাবে, Bazel config_setting
লক্ষ্যগুলির জন্য দৃশ্যমানতা প্রয়োগ করেনি যেগুলি একটি select()
এর কীগুলিতে উল্লেখ করা হয়েছে। এই উত্তরাধিকার আচরণ অপসারণ করার জন্য দুটি পতাকা আছে:
--incompatible_enforce_config_setting_visibility
এই লক্ষ্যগুলির জন্য দৃশ্যমানতা পরীক্ষা করতে সক্ষম করে। মাইগ্রেশনে সহায়তা করার জন্য, এটি এমন কোনওconfig_setting
ও ঘটায় যা একটিvisibility
নির্দিষ্ট করে না সর্বজনীন বলে বিবেচিত হবে (প্যাকেজ-স্তরেরdefault_visibility
নির্বিশেষে)।--incompatible_config_setting_private_default_visibility
র কারণেconfig_setting
হয় যা প্যাকেজেরdefault_visibility
মান্য করার জন্য একটিvisibility
নির্দিষ্ট করে না এবং প্রাইভেট ভিজিবিলিটির উপর ফলব্যাক করার জন্য, অন্য যেকোন নিয়ম টার্গেটের মতো। যদি--incompatible_enforce_config_setting_visibility
সেট করা না থাকে তাহলে এটি একটি নো-অপ।
উত্তরাধিকার আচরণের উপর নির্ভর করা এড়িয়ে চলুন। বর্তমান প্যাকেজের বাইরে ব্যবহার করার উদ্দেশ্যে যে কোনো config_setting
এর একটি সুস্পষ্ট visibility
থাকা উচিত, যদি প্যাকেজটি ইতিমধ্যেই একটি উপযুক্ত default_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()
-এর প্রতি কল শুধুমাত্র একবার হতে হবে, উপরের স্তরে (কোনও ফাংশনের ভিতরে নয়), এবং আদর্শভাবে অবিলম্বে 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
দেখতে পারে তার উপর নিয়ন্ত্রণ দেয়, কিন্তু আপনাকে কোনো অ-আন্ডারস্কোরড চিহ্ন লোড হওয়া থেকে আটকাতে দেয় না।
সৌভাগ্যবশত, আপনি সূক্ষ্ম-দানাযুক্ত নিয়ন্ত্রণ পেতে এই দুটি বৈশিষ্ট্য একত্রিত করতে পারেন।
# //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-দৃশ্যমানতা বিল্ডিফায়ার লিন্ট
একটি বিল্ডিফায়ার লিন্ট রয়েছে যা ব্যবহারকারীরা internal
বা private
নামে একটি ডিরেক্টরি থেকে একটি ফাইল লোড করলে একটি সতর্কতা প্রদান করে, যখন ব্যবহারকারীর ফাইলটি নিজেই সেই ডিরেক্টরির মূলের নীচে না থাকে। এই লিন্ট লোড দৃশ্যমানতা বৈশিষ্ট্যের পূর্ববর্তী এবং কর্মক্ষেত্রে অপ্রয়োজনীয় যেখানে .bzl
ফাইলগুলি দৃশ্যমানতা ঘোষণা করে।