Bazel 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>:--base_moduleके संदर्भ में दिए गए साफ़ तौर पर नाम के साथ रेपो.@@<repo_name>: दिए गए कैननिकल नाम के साथ रेपो.
मॉड्यूल की जानकारी देने वाले कॉन्टेक्स्ट में, मॉड्यूल से जुड़े डेटा रिपॉज़िट
के बारे में बताने वाले <arg>s का भी इस्तेमाल किया जा सकता है, न कि एक्सटेंशन से जनरेट किए गए डेटा स्टोर करने की जगहों के बारे में. वहीं, अगर किसी संदर्भ में डेटा का संग्रह तय करने की ज़रूरत होती है, तो मॉड्यूल के बारे में बताने वाले <arg>s का मतलब उस डेटा के रेपो में हो सकता है.
<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के लिए दो, और बाकी के लिए अनंत वैल्यू पर सेट होती है.--cyclesडिफ़ॉल्ट: "false": आउटपुट ग्राफ़ में चक्र के किनारे शामिल करें.--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को फ़िल्टर करता है.
उदाहरण
असल में 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>