mod कमांड, कई तरह के टूल उपलब्ध कराती है. इनसे उपयोगकर्ता को अपनी बाहरी डिपेंडेंसी के ग्राफ़ को समझने में मदद मिलती है. इसकी मदद से, डिपेंडेंसी ग्राफ़ को विज़ुअलाइज़ किया जा सकता है. साथ ही, यह पता लगाया जा सकता है कि ग्राफ़ में कोई मॉड्यूल या मॉड्यूल का वर्शन क्यों मौजूद है. इसके अलावा, मॉड्यूल को बैक अप देने वाली रिपॉज़िटरी की परिभाषाएं देखी जा सकती हैं. साथ ही, मॉड्यूल एक्सटेंशन और उनसे जनरेट होने वाली रिपॉज़िटरी के इस्तेमाल की जाँच की जा सकती है. इसके अलावा, और भी कई काम किए जा सकते हैं.
सिंटैक्स
bazel mod <subcommand> [<options>] [<arg> [<arg>...]]
उपलब्ध सब-कमांड और उनके लिए ज़रूरी आर्ग्युमेंट ये हैं:
graph: यह प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाता है. यह रूट मॉड्यूल से शुरू होता है. अगर--fromमें एक या उससे ज़्यादा मॉड्यूल तय किए गए हैं, तो ये मॉड्यूल सीधे तौर पर रूट के नीचे दिखाए जाते हैं. साथ ही, ग्राफ़ सिर्फ़ इनसे शुरू होता है (उदाहरण देखें).deps <arg>...: यहgraphकी तरह ही, तय किए गए हर मॉड्यूल की हल की गई डायरेक्ट डिपेंडेंसी दिखाता है.all_paths <arg>...: यह --from मॉड्यूल से टारगेट मॉड्यूल तक के सभी डिपेंडेंसी पाथ दिखाता है. आउटपुट को आसान बनाने के लिए, जब कई पाथ का एक ही सफ़िक्स होता है, तो सिर्फ़ सबसे छोटा पाथ दिखाया जाता है. उदाहरण के लिए, A -> B -> X दिखाया जाएगा, लेकिन A -> C -> B -> X को नहीं दिखाया जाएगा.path <arg>...: इसका मतलबall_pathsके जैसा ही होता है. हालांकि, यह--fromमॉड्यूल में से किसी एक मॉड्यूल से लेकर, आर्ग्युमेंट मॉड्यूल में से किसी एक मॉड्यूल तक का सिर्फ़ एक पाथ दिखाता है.explain <arg>...: इससे उन सभी जगहों के बारे में पता चलता है जहां डिपेंडेंसी ग्राफ़ में, चुने गए मॉड्यूल दिखते हैं. साथ ही, इससे उन मॉड्यूल के बारे में भी पता चलता है जो सीधे तौर पर उन पर निर्भर होते हैं.explainकमांड का आउटपुट,all_pathsकमांड का छोटा किया गया वर्शन होता है. इसमें ये चीज़ें शामिल होती हैं: 1) रूट मॉड्यूल; 2) रूट मॉड्यूल की ऐसी डिपेंडेंसी जो सीधे तौर पर आर्ग्युमेंट मॉड्यूल से जुड़ी होती हैं; 3) आर्ग्युमेंट मॉड्यूल की ऐसी डिपेंडेंसी जो सीधे तौर पर उनसे जुड़ी होती हैं; और 4) आर्ग्युमेंट मॉड्यूल (उदाहरण देखें).show_repo <arg>...: यह बताए गए रिपॉज़िटरी की परिभाषा दिखाता है. उदाहरण देखें.show_extension <extension>...: इससे, तय किए गए हर एक्सटेंशन के बारे में जानकारी दिखती है: जनरेट की गई रिपॉ की सूची,use_repoका इस्तेमाल करके उन्हें इंपोर्ट करने वाले मॉड्यूल, और हर उस मॉड्यूल में एक्सटेंशन के इस्तेमाल की सूची जहां इसका इस्तेमाल किया गया है. इसमें तय किए गए टैग औरuse_repoकॉल शामिल हैं (उदाहरण देखें).
<arg> का मतलब एक या उससे ज़्यादा मॉड्यूल या रेपो से है. यह इनमें से कोई एक हो सकता है:
लिटरल स्ट्रिंग
<root>: यह रूट मॉड्यूल है, जो आपके मौजूदा प्रोजेक्ट को दिखाता है.<name>@<version>: मॉड्यूल<name>, वर्शन<version>पर है. रजिस्ट्री से बाहर के किसी मॉड्यूल के लिए, अंडरस्कोर (_) को<version>के तौर पर इस्तेमाल करें.<name>: मॉड्यूल<name>के सभी मौजूदा वर्शन.@<repo_name>:--base_moduleके हिसाब से, दिए गए नाम वाला रेपो.@@<repo_name>: दिए गए कैननिकल नाम वाली रिपो.
ऐसे कॉन्टेक्स्ट में जहां मॉड्यूल के बारे में बताना ज़रूरी होता है वहां <arg>s का इस्तेमाल किया जा सकता है. ये ऐसे रिपॉज़िटरी होते हैं जो मॉड्यूल से जुड़े होते हैं. इनका इस्तेमाल एक्सटेंशन से जनरेट होने वाले रिपॉज़िटरी के बजाय किया जा सकता है. इसके उलट, अगर किसी कॉन्टेक्स्ट में रिपॉज़िटरी के बारे में बताना ज़रूरी है, तो मॉड्यूल के बारे में बताने वाले <arg>, उनसे जुड़ी रिपॉज़िटरी की जानकारी दे सकते हैं.
<extension>, <arg><label_to_bzl_file>%<extension_name> फ़ॉर्मैट में होना चाहिए.
<label_to_bzl_file> वाला हिस्सा, रिपॉज़िटरी के हिसाब से लेबल होना चाहिए. उदाहरण के लिए, //pkg/path:file.bzl.
नीचे दिए गए विकल्प, सिर्फ़ उन सब-कमांड पर लागू होते हैं जो ग्राफ़ प्रिंट करती हैं (graph, deps, all_paths, path, और explain):
--from <arg>[,<arg>[,...]]default:<root>: वे मॉड्यूल जिनसेgraph,all_paths,path, औरexplainमें ग्राफ़ को बड़ा किया जाता है. ज़्यादा जानकारी के लिए, सब-कमांड के ब्यौरे देखें.--verbosedefault: "false": आउटपुट ग्राफ़ में, हर मॉड्यूल के वर्शन रिज़ॉल्यूशन के बारे में ज़्यादा जानकारी शामिल करें. अगर समस्या हल करते समय मॉड्यूल का वर्शन बदल गया है, तो यह दिखाएं कि उसे किस वर्शन से बदला गया है या उसका ओरिजनल वर्शन क्या था, उसे क्यों बदला गया, और अगर इसकी वजह कम से कम वर्शन चुनना थी, तो यह दिखाएं कि किन मॉड्यूल ने नए वर्शन का अनुरोध किया था.--include_unuseddefault: "false": Include in the output graph the modules which were originally present in the dependency graph, but became unused after module resolution.--extension_info <mode>: आउटपुट ग्राफ़ में, मॉड्यूल एक्सटेंशन के इस्तेमाल के बारे में जानकारी शामिल करें (उदाहरण देखें).<mode>इनमें से कोई एक हो सकता है:hidden(डिफ़ॉल्ट): एक्सटेंशन के बारे में कुछ भी न दिखाएं.usages: हर उस मॉड्यूल के नीचे एक्सटेंशन दिखाएं जहां उनका इस्तेमाल किया गया है. इन्हें$<extension>के तौर पर प्रिंट किया जाता है.repos:usagesके अलावा, हर एक्सटेंशन के इस्तेमाल मेंuse_repoका इस्तेमाल करके इंपोर्ट की गई रिपो दिखाएं.all:usagesऔरreposके अलावा, एक्सटेंशन से जनरेट की गई ऐसी रिपॉज़िटरी भी दिखाएं जिन्हें किसी मॉड्यूल ने इंपोर्ट नहीं किया है. ये अतिरिक्त रिपो, आउटपुट में जनरेट करने वाले एक्सटेंशन के पहले उदाहरण के नीचे दिखती हैं. साथ ही, इन्हें डॉटेड एज से कनेक्ट किया जाता है.
--extension_filter <extension>[,<extension>[,...]]: अगर इस विकल्प को चुना जाता है, तो आउटपुट ग्राफ़ में सिर्फ़ वे मॉड्यूल शामिल होते हैं जो चुने गए एक्सटेंशन का इस्तेमाल करते हैं. साथ ही, उन मॉड्यूल तक पहुंचने के रास्ते भी शामिल होते हैं. एक्सटेंशन की खाली सूची (--extension_filter=में दिए गए तरीके से) तय करने का मतलब है कि डिपेंडेंसी ग्राफ़ में मौजूद किसी भी मॉड्यूल के लिए, all एक्सटेंशन का इस्तेमाल किया गया है.--depth <N>: आउटपुट ग्राफ़ की डेप्थ. डेप्थ 1 में सिर्फ़ रूट और उसकी सीधी डिपेंडेंसी दिखती हैं.explainके लिए डिफ़ॉल्ट वैल्यू 1,depsके लिए 2, और अन्य के लिए इनफ़िनिटी होती है.--cyclesdefault: "false": आउटपुट ग्राफ़ में साइकल के किनारों को शामिल करें.--include_builtindefault: "false": आउटपुट ग्राफ़ में, बिल्ट-इन मॉड्यूल (जैसे कि@bazel_tools) शामिल करें. यह फ़्लैग डिफ़ॉल्ट रूप से बंद होता है, क्योंकि बिल्ट-इन मॉड्यूल, हर दूसरे मॉड्यूल पर निर्भर होते हैं. इससे आउटपुट में बहुत ज़्यादा जानकारी शामिल हो जाती है.--charset <charset>default: utf8: टेक्स्ट आउटपुट के लिए इस्तेमाल किए जाने वाले वर्णसेट के बारे में बताएं. मान्य वैल्यू"utf8"और"ascii"हैं. इन दोनों के बीच सिर्फ़ एक बड़ा अंतर है."text"आउटपुट फ़ॉर्मैट में ग्राफ़ बनाने के लिए इस्तेमाल किए गए खास वर्ण,"ascii"वर्णमाला में मौजूद नहीं हैं. इसलिए,"ascii"वर्णसेट मौजूद है, ताकि इसका इस्तेमाल उन लेगसी प्लैटफ़ॉर्म पर भी किया जा सके जो यूनिकोड का इस्तेमाल नहीं कर सकते.--output <mode>: आउटपुट ग्राफ़ में, मॉड्यूल एक्सटेंशन के इस्तेमाल के बारे में जानकारी शामिल करें.<mode> इनमें से कोई एक हो सकता है:text(डिफ़ॉल्ट): आउटपुट ग्राफ़ को इस तरह से दिखाया जाता है कि उसे आसानी से समझा जा सके. इसे ट्री के तौर पर दिखाया जाता है.json: यह विकल्प, ग्राफ़ को JSON ऑब्जेक्ट के तौर पर दिखाता है. इसे ट्री के तौर पर फ़्लैट किया जाता है.graph: इस विकल्प का इस्तेमाल करने पर, ग्राफ़ को Graphviz dot फ़ॉर्मैट में दिखाया जाता है.
bazel mod graph --output graph | dot -Tsvg > /tmp/graph.svg
दूसरे विकल्पों में ये शामिल हैं:
--base_module <arg>default:<root>: उस मॉड्यूल के बारे में बताएं जिसके हिसाब से, तर्कों में मौजूद रिपॉज़िटरी के नामों का मतलब निकाला जाता है. ध्यान दें कि यह आर्ग्युमेंट,@<repo_name>के फ़ॉर्म में हो सकता है. इसकी व्याख्या हमेशा रूट मॉड्यूल के हिसाब से की जाती है.--extension_usages <arg>[,<arg>[,...]]: यहshow_extensionको फ़िल्टर करके, सिर्फ़ तय किए गए मॉड्यूल से एक्सटेंशन के इस्तेमाल की जानकारी दिखाता है.
उदाहरण
यहां कुछ उदाहरण दिए गए हैं, जिनसे आपको यह पता चलेगा कि किसी असली Bazel प्रोजेक्ट पर mod कमांड का इस्तेमाल कैसे किया जा सकता है. इससे आपको यह भी पता चलेगा कि इस कमांड का इस्तेमाल करके, अपने प्रोजेक्ट की बाहरी डिपेंडेंसी की जांच कैसे की जा सकती है.
MODULE.bazel फ़ाइल:
module(
name = "my_project",
version = "1.0",
)
bazel_dep(name = "bazel_skylib", version = "1.1.1", repo_name = "skylib1")
bazel_dep(name = "bazel_skylib", version = "1.2.0", repo_name = "skylib2")
multiple_version_override(module_name = "bazel_skylib", versions = ["1.1.1", "1.2.0"])
bazel_dep(name = "stardoc", version = "0.5.0")
bazel_dep(name = "rules_java", version = "5.0.0")
toolchains = use_extension("@rules_java//java:extensions.bzl", "toolchains")
use_repo(toolchains, my_jdk="remotejdk17_linux")
|
|
अपने प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाएं.
bazel mod graph<root> (my_project@1.0) ├───bazel_skylib@1.1.1 │ └───platforms@0.0.4 ├───bazel_skylib@1.2.0 │ └───platforms@0.0.4 ... ├───rules_java@5.0.0 │ ├───platforms@0.0.4 ... │ ├───rules_cc@0.0.1 │ │ ├───bazel_skylib@1.1.1 ... │ │ └───platforms@0.0.4 ... │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.1.1 ... │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 ├───bazel_skylib@1.1.1 ... └───rules_java@5.0.0 ...पूरा डिपेंडेंसी ग्राफ़ दिखाएं. इसमें ऐसे मॉड्यूल भी शामिल होते हैं जिनका इस्तेमाल नहीं किया गया है. साथ ही, वर्शन रिज़ॉल्यूशन के बारे में अतिरिक्त जानकारी भी शामिल होती है.
bazel mod graph --include_unused --verbose<root> (my_project@1.0) ├───bazel_skylib@1.1.1 │ └───platforms@0.0.4 ├───bazel_skylib@1.2.0 │ └───platforms@0.0.4 ... ├───rules_java@5.0.0 │ ├───platforms@0.0.4 ... │ ├───rules_cc@0.0.1 │ │ ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override) │ │ ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ │ └───platforms@0.0.4 ... │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override) │ ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) ├───rules_java@5.0.0 ... (was 4.0.0, cause <root>, bazel_tools@_) ├───bazel_skylib@1.0.3 (to 1.1.1, cause multiple_version_override) │ └───platforms@0.0.4 ... └───rules_java@4.0.0 (to 5.0.0, cause <root>, bazel_tools@_) ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override) └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)कुछ खास मॉड्यूल से, डिपेंडेंसी ग्राफ़ को बड़ा करके दिखाएं.
bazel mod graph --from rules_java --include_unused<root> (my_project@1.0) ├───rules_java@5.0.0 │ ├───platforms@0.0.4 │ ├───rules_cc@0.0.1 │ │ ├───bazel_skylib@1.0.3 ... (unused) │ │ ├───bazel_skylib@1.1.1 ... │ │ └───platforms@0.0.4 ... │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.0.3 ... (unused) │ ├───bazel_skylib@1.1.1 ... │ └───rules_cc@0.0.1 ... └╌╌rules_java@4.0.0 (unused) ├───bazel_skylib@1.0.3 (unused) │ └───platforms@0.0.4 ... └───bazel_skylib@1.1.1 └───platforms@0.0.4 ...अपने दो मॉड्यूल के बीच के सभी पाथ दिखाएं.
bazel mod all_paths bazel_skylib@1.1.1 --from rules_proto<root> (my_project@1.0) └╌╌rules_proto@4.0.0 ├───bazel_skylib@1.1.1 └───rules_cc@0.0.1 └───bazel_skylib@1.1.1 ...देखें कि आपका प्रोजेक्ट कुछ मॉड्यूल पर क्यों और कैसे निर्भर करता है.
bazel mod explain @skylib1 --verbose --include_unused<root> (my_project@1.0) ├───bazel_skylib@1.1.1 ├───rules_java@5.0.0 │ ├───rules_cc@0.0.1 │ │ └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) ├╌╌rules_cc@0.0.1 │ └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) └╌╌rules_proto@4.0.0 ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) └───rules_cc@0.0.1 ...अपने कुछ मॉड्यूल के रिपॉज़िटरी के मूल नियम देखें.
bazel mod show_repo rules_cc stardoc## rules_cc@0.0.1: # <builtin> http_archive( name = "rules_cc+", urls = ["https://bcr.bazel.build/test-mirror/github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz", "https://github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz"], integrity = "sha256-Tcy/0iwN7xZMj0dFi9UODHFI89kgAs20WcKpamhJgkE=", strip_prefix = "", remote_patches = {"https://bcr.bazel.build/modules/rules_cc/0.0.1/patches/add_module_extension.patch": "sha256-g3+zmGs0YT2HKOVevZpN0Jet89Ylw90Cp9XsIAY8QqU="}, remote_patch_strip = 1, ) # Rule http_archive defined at (most recent call last): # /home/user/.cache/bazel/_bazel_user/6e893e0f5a92cc4cf5909a6e4b2770f9/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31 in <toplevel> ## stardoc: # <builtin> http_archive( name = "stardoc+", urls = ["https://bcr.bazel.build/test-mirror/github.com/bazelbuild/stardoc/releases/download/0.5.0/stardoc-0.5.0.tar.gz", "https://github.com/bazelbuild/stardoc/releases/download/0.5.0/stardoc-0.5.0.tar.gz"], integrity = "sha256-yXlNzIAmow/2fPfPkeviRcopSyCwcYRdEsGSr+JDrXI=", strip_prefix = "", remote_patches = {}, remote_patch_strip = 0, ) # Rule http_archive defined at (most recent call last): # /home/user/.cache/bazel/_bazel_user/6e893e0f5a92cc4cf5909a6e4b2770f9/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31 in <toplevel>देखें कि आपके डिपेंडेंसी ग्राफ़ में किन मॉड्यूल एक्सटेंशन का इस्तेमाल किया गया है.
bazel mod graph --extension_info=usages --extension_filter=all<root> (my_project@1.0) ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains ├───rules_java@5.0.0 # │ ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains │ ├───rules_cc@0.0.1 # │ │ └───$@@rules_cc.0.0.1//bzlmod:extensions.bzl%cc_configure │ └───rules_proto@4.0.0 │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 └───rules_java@5.0.0 ...देखें कि डिपेंडेंसी ग्राफ़ के हिस्से के तौर पर, कुछ खास एक्सटेंशन से कौनसी रिपॉज़िटरी जनरेट और इंपोर्ट की जाती हैं.
bazel mod show_extension @@rules_java+5.0.0//java:extensions.bzl%toolchains<root> (my_project@1.0) ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains │ ├───remotejdk17_linux │ ├╌╌remotejdk11_linux │ ├╌╌remotejdk11_linux_aarch64 │ ├╌╌remotejdk11_linux_ppc64le │ ├╌╌remotejdk11_linux_s390x ...(some lines omitted)... ├───rules_java@5.0.0 # │ └───$@@rules_java.5.0.0//java:extensions.bzl%toolchains ... │ ├───local_jdk │ ├───remote_java_tools │ ├───remote_java_tools_darwin │ ├───remote_java_tools_linux │ ├───remote_java_tools_windows │ ├───remotejdk11_linux_aarch64_toolchain_config_repo │ ├───remotejdk11_linux_ppc64le_toolchain_config_repo ...(some lines omitted)... └───stardoc@0.5.0 └───rules_java@5.0.0 ...किसी एक्सटेंशन की जनरेट की गई रिपॉज़िटरी की सूची देखें. साथ ही, यह देखें कि हर मॉड्यूल में उस एक्सटेंशन का इस्तेमाल कैसे किया जाता है.
bazel mod graph --extension_info=all --extension_filter=@rules_java//java:extensions.bzl%toolchains## @@rules_java.5.0.0//java:extensions.bzl%toolchains: Fetched repositories: - local_jdk (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools_darwin (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools_linux (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools_windows (imported by bazel_tools@_, rules_java@5.0.0) - remotejdk11_linux_aarch64_toolchain_config_repo (imported by rules_java@5.0.0) - remotejdk11_linux_ppc64le_toolchain_config_repo (imported by rules_java@5.0.0) ...(some lines omitted)... - remotejdk17_linux (imported by <root>) - remotejdk11_linux - remotejdk11_linux_aarch64 - remotejdk11_linux_ppc64le - remotejdk11_linux_s390x - remotejdk11_macos ...(some lines omitted)... # Usage in <root> at <root>/MODULE.bazel:14:27 with the specified attributes: use_repo( toolchains, my_jdk="remotejdk17_linux", ) # Usage in bazel_tools@_ at bazel_tools@_/MODULE.bazel:23:32 with the specified attributes: use_repo( toolchains, "local_jdk", "remote_java_tools", "remote_java_tools_linux", "remote_java_tools_windows", "remote_java_tools_darwin", ) # Usage in rules_java@5.0.0 at rules_java@5.0.0/MODULE.bazel:30:27 with the specified attributes: use_repo( toolchains, "remote_java_tools", "remote_java_tools_linux", "remote_java_tools_windows", "remote_java_tools_darwin", "local_jdk", "remotejdk11_linux_toolchain_config_repo", "remotejdk11_macos_toolchain_config_repo", "remotejdk11_macos_aarch64_toolchain_config_repo", ...(some lines omitted)... )एक्सटेंशन से जनरेट की गई कुछ रिपॉज़िटरी के मूल नियम देखें.
bazel mod show_repo --base_module=rules_java @remote_java_tools## @remote_java_tools: # <builtin> http_archive( name = "rules_java++toolchains+remote_java_tools", urls = ["https://mirror.bazel.build/bazel_java_tools/releases/java/v11.5/java_tools-v11.5.zip", "https://github.com/bazelbuild/java_tools/releases/download/java_v11.5/java_tools-v11.5.zip"], sha256 = "b763ee80e5754e593fd6d5be6d7343f905bc8b73d661d36d842b024ca11b6793", ) # Rule http_archive defined at (most recent call last): # /home/user/.cache/bazel/_bazel_user/6e893e0f5a92cc4cf5909a6e4b2770f9/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31 in <toplevel>