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>:--base_moduleके मामले में, दिए गए साफ़ नाम वाला रेपो.@@<repo_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")
|
|
अपने प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाएं.
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>