Basel 6.3.0 में पेश किया गया mod कमांड, मदद करने के लिए कई टूल उपलब्ध कराता है
Bzlmod चालू होने पर, उपयोगकर्ता अपने बाहरी डिपेंडेंसी ग्राफ़ को समझता है. यह
की मदद से डिपेंडेंसी ग्राफ़ को विज़ुअलाइज़ किया जा सकता है, यह पता लगाया जा सकता है कि कोई खास मॉड्यूल या
मॉड्यूल का एक वर्शन, ग्राफ़ में मौजूद है, तो रेपो की परिभाषाएं देखें
मॉड्यूल, मॉड्यूल एक्सटेंशन के इस्तेमाल का निरीक्षण करें और उनसे जनरेट होने वाले रिपोज जैसे
दूसरे फ़ंक्शन.
सिंटैक्स
bazel mod <subcommand> [<options>] [<arg> [<arg>...]]
उपलब्ध सब-कमांड और उनसे जुड़े ज़रूरी तर्क ये हैं:
graph: प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाता है, जहां से शुरू होता है रूट मॉड्यूल की तरह हो सकता है. अगर--fromमें एक या ज़्यादा मॉड्यूल बताए गए हैं, तो ये मॉड्यूल सीधे रूट के नीचे दिखाए जाते हैं और ग्राफ़ को सिर्फ़ बड़ा किया जाता है इनसे शुरू होते हैं (उदाहरण देखें).deps <arg>...: यह नीचे दी गई हर स्थिति की रिज़ॉल्व की गई डायरेक्ट डिपेंडेंसी दिखाता है बताए गए मॉड्यूल की तरह है, जोgraphकी तरह है.all_paths <arg>...: रूट से लेकर<arg>...बताया गया. अगर--fromमें एक या एक से ज़्यादा मॉड्यूल बताए गए हैं, तो ये मॉड्यूल सीधे रूट के नीचे दिखाए जाते हैं और ग्राफ़ में--fromमॉड्यूल से आर्ग्युमेंट मॉड्यूल तक का कोई मौजूदा पाथ (देखें उदाहरण) के साथ दिखाया जाता है.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>:<version>वर्शन पर मॉड्यूल<name>. मॉड्यूल के लिए गैर-रजिस्ट्री ओवरराइड के साथ,<version>के तौर पर अंडरस्कोर (_) का इस्तेमाल करें.<name>:<name>मॉड्यूल के सभी मौजूदा वर्शन.@<repo_name>: दिए गए पैरंट के साथ डेटा स्टोर करने की जगह name के संदर्भ में--base_module.@@<repo_name>: दिए गए कैननिकल के साथ डेटा स्टोर करने की जगह name.
मॉड्यूल के बारे में बताने वाले संदर्भ में, <arg> का मतलब उस डेटा को स्टोर करना है
के मुताबिक मॉड्यूल (एक्सटेंशन जनरेट किए गए रेपो के उलट) भी ऐसा हो सकता है
इस्तेमाल किया गया. इसके ठीक उलट, एक ऐसे कॉन्टेक्स्ट में रिपोज़ की जानकारी देना ज़रूरी होता है जिसमें <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>[,...]]डिफ़ॉल्ट:<root>: वह मॉड्यूल जिससे ग्राफ़ कोgraph,all_paths,path, औरexplainमें बड़ा किया गया है. इस्तेमाल की जानकारी द सबकमैंड्स' देखें.--verboseडिफ़ॉल्ट: "गलत": आउटपुट ग्राफ़ में अतिरिक्त शामिल करें हर मॉड्यूल के वर्शन रिज़ॉल्यूशन के बारे में जानकारी. अगर मॉड्यूल रिज़ॉल्यूशन के दौरान बदला गया वर्शन दिखाता है, तो दिखाएं कि इसे किस वर्शन से बदला गया है या ओरिजनल वर्शन क्या था, इसे बदलने की वजह, और कौनसे मॉड्यूल अगर वजह कम से कम वर्शन थी, तो नए वर्शन का अनुरोध किया था चुनें.--include_unusedडिफ़ॉल्ट: "गलत": आउटपुट ग्राफ़ में ऐसे मॉड्यूल जो मूल रूप से डिपेंडेंसी ग्राफ़ में मौजूद थे, लेकिन मॉड्यूल रिज़ॉल्यूशन के बाद इस्तेमाल नहीं किया जाता.--extension_info <mode>: मॉड्यूल एक्सटेंशन के बारे में जानकारी शामिल करें आउटपुट ग्राफ़ के हिस्से के तौर पर इस्तेमाल हुए हैं (उदाहरण देखें).<mode>अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इनमें से एक हो सकता है:hidden(डिफ़ॉल्ट): एक्सटेंशन के बारे में कुछ भी न दिखाएं.usages: हर मॉड्यूल के नीचे एक्सटेंशन दिखाएं जहां उनका इस्तेमाल किया जाता है. वे$<extension>के फ़ॉर्मैट में प्रिंट किए जाते हैं.repos:usagesके अलावा, इसका इस्तेमाल करके इंपोर्ट किए गए रेपो को दिखाएंuse_repoके तहत, हर एक्सटेंशन के इस्तेमाल पर लागू होती है.all:usagesऔरreposके अलावा, यह भी दिखाएं एक्सटेंशन से जनरेट किए गए ऐसे डेटा संग्रह स्थान हैं जिन्हें किसी भी मॉड्यूल से इंपोर्ट नहीं किया जाता है. ये डेटा स्टोर करने की अतिरिक्त जगहों को, जनरेट होने के दौरान पहली बार दिखने के नीचे दिखाया जाता है एक्सटेंशन भी होते हैं और बिंदु वाले किनारे से जुड़े होते हैं.
--extension_filter <extension>[,<extension>[,...]]: अगर तय किया गया है, तो आउटपुट ग्राफ़ में सिर्फ़ ऐसे मॉड्यूल शामिल हैं जो तय एक्सटेंशन का इस्तेमाल करते हैं, और का पाथ, जो उन मॉड्यूल पर ले जाता है. एक्सटेंशन की एक खाली सूची तय करना (जैसा--extension_filter=में) का मतलब है, इस्तेमाल किए गए सभी एक्सटेंशन तय करना डिपेंडेंसी ग्राफ़ में किसी भी मॉड्यूल के मुताबिक बनाया जा सकता है.--depth <N>: आउटपुट ग्राफ़ की डेप्थ. 1 की गहराई सिर्फ़ रूट और इसकी डायरेक्ट डिपेंडेंसी. यह वैल्यू,explainके लिए 1 औरdepsके लिए 2 पर सेट होती है और अन्य के लिए अनंत संख्या में हैं.--cyclesडिफ़ॉल्ट: "गलत": आउटपुट ग्राफ़ में साइकल के किनारे शामिल करें.--include_builtinडिफ़ॉल्ट: "गलत": इसमें बिल्ट-इन मॉड्यूल शामिल होते हैं (जैसे कि@bazel_toolsआउटपुट ग्राफ़ में. यह फ़्लैग डिफ़ॉल्ट रूप से बंद होता है, क्योंकि बिल्ट-इन मॉड्यूल पूरी तरह से हर दूसरे मॉड्यूल पर निर्भर होते हैं, जो आउटपुट को बहुत ज़्यादा व्यवस्थित कर देता है.--charset <charset>डिफ़ॉल्ट: utf8: टेक्स्ट के लिए इस्तेमाल किया जाने वाला वर्णसेट तय करें आउटपुट. मान्य वैल्यू,"utf8"और"ascii"हैं. सिर्फ़ सबसे अहम अंतर उन विशेष वर्णों में है जिनका इस्तेमाल ग्राफ़ बनाने के लिए किया जाता है"text"आउटपुट फ़ॉर्मैट, जो"ascii"वर्णसेट में मौजूद नहीं है. इसलिए,"ascii"वर्णसेट इन पर भी उपयोग का समर्थन करता है यूनिकोड का इस्तेमाल नहीं कर सकने वाले लेगसी प्लैटफ़ॉर्म.--output <mode>: मॉड्यूल एक्सटेंशन के इस्तेमाल से जुड़ी जानकारी को इस तौर पर शामिल करें आउटपुट ग्राफ़ का हिस्सा है.<mode> इनमें से एक हो सकता है:text(डिफ़ॉल्ट): आउटपुट ग्राफ़ की ऐसी जानकारी जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है (पेड़ की तरह चपटा).json: ग्राफ़ को JSON ऑब्जेक्ट के रूप में आउटपुट करता है (जैसा कि पेड़).graph: ग्राफ़विज़ डॉट निरूपण में ग्राफ़ का आउटपुट देता है.
bazel mod graph --output graph | dot -Tsvg > /tmp/graph.svg
दूसरे विकल्पों में ये शामिल हैं:
--base_module <arg>डिफ़ॉल्ट:<root>: इससे मिलता-जुलता मॉड्यूल तय करें जिसे आर्ग्युमेंट में, साफ़ तौर पर दिखाए जाने वाले रेपो नेम की व्याख्या की गई हो. ध्यान दें कि यह@<repo_name>के रूप में हो सकता है; यह हमेशा होता है रूट मॉड्यूल के सापेक्ष व्याख्या की जाती है.--extension_usages <arg>[,<arg>[,...]]:show_extensionको सिर्फ़ फ़िल्टर करता है खास मॉड्यूल से एक्सटेंशन के इस्तेमाल दिखाता है.
उदाहरण
रीयल बेज़ल प्रोजेक्ट में, 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")
|
|
अपने Google Tag Manager का पूरा डिपेंडेंसी ग्राफ़ दिखाना प्रोजेक्ट.
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>