अक्सर पूछे जाने वाले सवाल

इस पेज पर, Bazel में बाहरी डिपेंडेंसी के बारे में अक्सर पूछे जाने वाले कुछ सवालों के जवाब दिए गए हैं.

MODULE.bazel

मुझे Bazel मॉड्यूल का वर्शन कैसे बनाना चाहिए?

सोर्स आर्काइव MODULE.bazel में module डायरेक्टिव के साथ version सेट करने से कई नुकसान हो सकते हैं. साथ ही, अनचाहे साइड इफ़ेक्ट भी हो सकते हैं. हालांकि, ऐसा तब होता है, जब इसे सावधानी से मैनेज न किया जाए:

• डुप्लीकेट होना: किसी मॉड्यूल का नया वर्शन रिलीज़ करने के लिए, आम तौर पर MODULE.bazel में वर्शन को बढ़ाना और रिलीज़ को टैग करना होता है. ये दो अलग-अलग चरण हैं, जो सिंक नहीं हो सकते. ऑटोमेशन की मदद से इस जोखिम को कम किया जा सकता है. हालांकि, इससे बचने का सबसे आसान और सुरक्षित तरीका यह है कि आप इसे पूरी तरह से बंद कर दें.

• वर्शन में अंतर: रजिस्ट्री से बाहर के ओवरराइड का इस्तेमाल करके, किसी खास कमिट के साथ मॉड्यूल को ओवरराइड करने वाले उपयोगकर्ताओं को गलत वर्शन दिखेगा. उदाहरण के लिए, अगर सोर्स आर्काइव में MODULE.bazel, version = "0.3.0" सेट करता है, लेकिन उस रिलीज़ के बाद अतिरिक्त कमिट किए गए हैं, तो उन कमिट में से किसी एक के साथ ओवरराइड करने वाले उपयोगकर्ता को अब भी 0.3.0 दिखेगा. असल में, वर्शन को यह दिखाना चाहिए कि यह रिलीज़ से पहले का वर्शन है. उदाहरण के लिए, 0.3.1-rc1.

• रजिस्ट्री से बाहर के ओवरराइड से जुड़ी समस्याएं: प्लेसहोल्डर वैल्यू का इस्तेमाल करने से समस्याएं हो सकती हैं. ऐसा तब होता है, जब उपयोगकर्ता किसी मॉड्यूल को रजिस्ट्री से बाहर के ओवरराइड से बदलता है. उदाहरण के लिए, 0.0.0 को सबसे ज़्यादा प्राथमिकता वाला वर्शन नहीं माना जाता. आम तौर पर, उपयोगकर्ता यही चाहते हैं कि जब वे रजिस्ट्री से बाहर की सेटिंग को बदल रहे हों, तो उन्हें सबसे ज़्यादा प्राथमिकता वाला वर्शन मिले.

इसलिए, सोर्स आर्काइव MODULE.bazel में वर्शन सेट न करना ही बेहतर होता है. इसके बजाय, इसे रजिस्ट्री में सेव किए गए MODULE.bazel में सेट करें. उदाहरण के लिए, Bazel Central Registry. यह Bazel के बाहरी डिपेंडेंसी रिज़ॉल्यूशन के दौरान, मॉड्यूल के वर्शन की असल जानकारी देने वाला सोर्स होता है. Bazel registries देखें.

आम तौर पर, यह प्रोसेस अपने-आप होती है. उदाहरण के लिए, rules-template उदाहरण के तौर पर दी गई नियम वाली रिपॉज़िटरी, BCR पर रिलीज़ पब्लिश करने के लिए bazel-contrib/publish-to-bcr publish.yaml GitHub ऐक्शन का इस्तेमाल करती है. इस कार्रवाई से, रिलीज़ वर्शन के साथ सोर्स संग्रह MODULE.bazel के लिए पैच जनरेट होता है. यह पैच, रजिस्ट्री में सेव किया जाता है. इसे तब लागू किया जाता है, जब Bazel की बाहरी डिपेंडेंसी को हल करने के दौरान मॉड्यूल फ़ेच किया जाता है.

इस तरह, रजिस्ट्री में रिलीज़ किए गए वर्शन को सही तरीके से सेट किया जाएगा. इससे bazel_dep, single_version_override, और multiple_version_override उम्मीद के मुताबिक काम करेंगे. साथ ही, रजिस्ट्री के बाहर से ओवरराइड करने पर होने वाली संभावित समस्याओं से बचा जा सकेगा. ऐसा इसलिए, क्योंकि सोर्स आर्काइव में मौजूद वर्शन, डिफ़ॉल्ट वैल्यू ('') होगा. इसे हमेशा सही तरीके से हैंडल किया जाएगा. यह डिफ़ॉल्ट वर्शन वैल्यू है. साथ ही, क्रम से लगाने पर यह उम्मीद के मुताबिक काम करेगा. खाली स्ट्रिंग को सबसे ज़्यादा वर्शन माना जाता है.

कंपैटिबिलिटी लेवल क्या होता है?

आपको compatibility_level का इस्तेमाल बंद कर देना चाहिए.

compatibility_level बढ़ाने से वर्शन में टकराव होता है. इसे ठीक करने में असली उपयोगकर्ताओं को मुश्किल होती है. इसलिए, Bazel 8.6.0 और 9.1.0 से शुरू होने वाले वर्शन में, compatibility_level और max_compatibility_level, दोनों नो-ऑप हैं.

मॉड्यूल के रखरखाव करने वाले लोगों को यह पक्का करना चाहिए कि नुकसान पहुंचाने वाले बड़े बदलावों की वजह से, बिल्ड फ़ेल होने पर गड़बड़ी के मैसेज साफ़ तौर पर दिखें. साथ ही, माइग्रेट करने के लिए कार्रवाई की जा सकने वाले पाथ उपलब्ध हों.

लेगसी दस्तावेज़:

Bazel मॉड्यूल के compatibility_level को उसी कमिट में बढ़ाना चाहिए जिसमें पुराने सिस्टम के साथ काम न करने वाला ("ब्रेकिंग") बदलाव किया गया हो.

हालांकि, अगर Bazel को पता चलता है कि हल किए गए डिपेंडेंसी ग्राफ़ में, एक ही मॉड्यूल के ऐसे वर्शन मौजूद हैं जिनके कंपैटिबिलिटी लेवल अलग-अलग हैं, तो वह गड़बड़ी दिखा सकता है. ऐसा तब हो सकता है, जब उदाहरण के लिए, दो मॉड्यूल अलग-अलग कंपैटिबिलिटी लेवल वाले तीसरे मॉड्यूल के वर्शन पर निर्भर हों.

इसलिए, compatibility_level को बार-बार बढ़ाने से, उपयोगकर्ताओं को काफ़ी परेशानी हो सकती है. इसलिए, ऐसा न करने का सुझाव दिया जाता है. इस स्थिति से बचने के लिए, compatibility_level को सिर्फ़ तब बढ़ाना चाहिए, जब बड़े बदलाव से इस्तेमाल के ज़्यादातर मामलों पर असर पड़ता हो और माइग्रेट करना और/या समस्या हल करना आसान न हो.

MODULE.bazel में loads का इस्तेमाल क्यों नहीं किया जा सकता?

डिपेंडेंसी रिज़ॉल्यूशन के दौरान, रेफ़र की गई सभी बाहरी डिपेंडेंसी की MODULE.bazel फ़ाइलें, रजिस्ट्री से फ़ेच की जाती हैं. इस चरण में, अब तक डिपेंडेंसी के सोर्स संग्रह नहीं लाए गए हैं. इसलिए, अगर MODULE.bazel फ़ाइल load कोई दूसरी फ़ाइल है, तो Bazel के पास पूरे सोर्स संग्रह को फ़ेच किए बिना उस फ़ाइल को फ़ेच करने का कोई तरीका नहीं है. ध्यान दें कि MODULE.bazel फ़ाइल अपने-आप में खास होती है, क्योंकि इसे सीधे तौर पर रजिस्ट्री पर होस्ट किया जाता है.

ऐसे कुछ मामले होते हैं जिनमें loads in MODULE.bazel का अनुरोध करने वाले लोगों की दिलचस्पी होती है. इन्हें loads के बिना भी हल किया जा सकता है:

• यह पक्का करना कि MODULE.bazel में दिया गया वर्शन, किसी दूसरी जगह सेव किए गए बिल्ड मेटाडेटा से मेल खाता हो. उदाहरण के लिए, .bzl फ़ाइल में: ऐसा करने के लिए, BUILD फ़ाइल से लोड की गई .bzl फ़ाइल में native.module_version तरीके का इस्तेमाल किया जा सकता है.
• बहुत बड़ी MODULE.bazel फ़ाइल को मैनेज किए जा सकने वाले सेक्शन में बांटना. खास तौर पर, मोनोरिपो के लिए: रूट मॉड्यूल, include डायरेक्टिव का इस्तेमाल करके, अपनी MODULE.bazel फ़ाइल को कई सेगमेंट में बांट सकता है. इसी वजह से, हम MODULE.bazel फ़ाइलों में loads इस्तेमाल करने की अनुमति नहीं देते. साथ ही, include का इस्तेमाल नॉन-रूट मॉड्यूल में नहीं किया जा सकता.
• WORKSPACE के पुराने सिस्टम का इस्तेमाल करने वाले लोगों को, शायद यह याद होगा कि वे किसी रिपो का एलान करते थे. इसके बाद, वे जटिल लॉजिक को लागू करने के लिए, उस रिपो से तुरंत load करते थे. इस सुविधा को मॉड्यूल एक्सटेंशन से बदल दिया गया है.

क्या bazel_dep के लिए SemVer रेंज तय की जा सकती है?

नहीं. npm और Cargo जैसे कुछ अन्य पैकेज मैनेजर, वर्शन रेंज (इंप्लिसिट या एक्सप्लिसिट तौर पर) के साथ काम करते हैं. इसके लिए, अक्सर कंस्ट्रेंट सॉल्वर की ज़रूरत होती है. इससे उपयोगकर्ताओं के लिए आउटपुट का अनुमान लगाना मुश्किल हो जाता है. साथ ही, लॉकफ़ाइल के बिना वर्शन रिज़ॉल्यूशन को दोहराया नहीं जा सकता.

इसके बजाय, Bazel कम से कम वर्शन चुनने की सुविधा का इस्तेमाल करता है. जैसे, Go. इससे आउटपुट का अनुमान लगाना आसान हो जाता है और यह पक्का किया जा सकता है कि इसे फिर से बनाया जा सकता है. यह एक ट्रेडऑफ़ है, जो Bazel के डिज़ाइन के लक्ष्यों से मेल खाता है.

इसके अलावा, Bazel मॉड्यूल के वर्शन, SemVer के सुपरसेट होते हैं. इसलिए, SemVer के सख्त एनवायरमेंट में जो सही लगता है वह हमेशा Bazel मॉड्यूल के वर्शन में लागू नहीं होता.

क्या मुझे किसी bazel_dep के लिए, अपने-आप नया वर्शन मिल सकता है?

कुछ उपयोगकर्ता कभी-कभी यह सुविधा मांगते हैं कि वे bazel_dep(name = "foo", version = "latest") को सेट कर सकें, ताकि उन्हें किसी डिप्लॉयमेंट का नया वर्शन अपने-आप मिल जाए. यह SemVer रेंज के बारे में पूछे गए सवाल के जैसा ही है. इसका जवाब भी नहीं है.

हमारा सुझाव है कि इस काम के लिए ऑटोमेशन का इस्तेमाल करें. उदाहरण के लिए, Renovate, Bazel मॉड्यूल के साथ काम करता है.

कभी-कभी, यह सवाल पूछने वाले लोग, लोकल डेवलपमेंट के दौरान तेज़ी से दोहराने का तरीका ढूंढ रहे होते हैं. इसके लिए, local_path_override का इस्तेमाल किया जा सकता है.

ये सभी use_repo क्यों दिख रहे हैं?

MODULE.bazel फ़ाइलों में मॉड्यूल एक्सटेंशन के इस्तेमाल के लिए, कभी-कभी बड़े use_repo डायरेक्टिव का इस्तेमाल किया जाता है. उदाहरण के लिए, gazelle से go_deps एक्सटेंशन का सामान्य इस्तेमाल कुछ ऐसा दिख सकता है:

go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
use_repo(
    go_deps,
    "com_github_gogo_protobuf",
    "com_github_golang_mock",
    "com_github_golang_protobuf",
    "org_golang_x_net",
    ...  # potentially dozens of lines...
)

लंबा use_repo डायरेक्टिव शायद ज़रूरत से ज़्यादा लगे, क्योंकि जानकारी पहले से ही रेफ़र की गई go.mod फ़ाइल में मौजूद है.

Bazel को इस use_repo डायरेक्टिव की ज़रूरत इसलिए होती है, क्योंकि यह मॉड्यूल एक्सटेंशन को लेज़ी तरीके से चलाता है. इसका मतलब है कि मॉड्यूल एक्सटेंशन सिर्फ़ तब चलता है, जब उसके नतीजे देखे जाते हैं. मॉड्यूल एक्सटेंशन का "आउटपुट" रेपो की परिभाषाएं होती हैं. इसका मतलब है कि हम किसी मॉड्यूल एक्सटेंशन को सिर्फ़ तब चलाते हैं, जब उसके ज़रिए तय किए गए रेपो का अनुरोध किया जाता है. उदाहरण के लिए, अगर ऊपर दिए गए उदाहरण में टारगेट @org_golang_x_net//:foo बनाया जाता है. हालांकि, हमें यह नहीं पता होता कि मॉड्यूल एक्सटेंशन किन रिपॉज़िटरी को तय करेगा. यह जानकारी हमें मॉड्यूल एक्सटेंशन को चलाने के बाद ही मिलती है. यहां use_repo डायरेक्टिव काम आता है. उपयोगकर्ता, Bazel को बता सकता है कि उसे एक्सटेंशन से कौनसी रिपो जनरेट करने की उम्मीद है. इसके बाद, Bazel सिर्फ़ तब एक्सटेंशन चलाएगा, जब इन खास रिपो का इस्तेमाल किया जाएगा.

use_repo डायरेक्टिव को बनाए रखने के लिए, मॉड्यूल एक्सटेंशन अपने लागू करने वाले फ़ंक्शन से extension_metadata ऑब्जेक्ट दिखा सकता है. उपयोगकर्ता, इन मॉड्यूल एक्सटेंशन के लिए use_repo डायरेक्टिव अपडेट करने के लिए, bazel mod tidy कमांड चला सकता है.

Bzlmod माइग्रेशन

सबसे पहले किस फ़ाइल का आकलन किया जाता है, MODULE.bazel या WORKSPACE?

जब --enable_bzlmod और --enable_workspace, दोनों सेट होते हैं, तो यह जानना ज़रूरी हो जाता है कि किस सिस्टम से पहले सलाह ली जाती है. इसका जवाब यह है कि सबसे पहले MODULE.bazel (Bzlmod) का आकलन किया जाता है.

इसका जवाब यह है कि "कौनसा पहले जांच करता है" पूछना सही सवाल नहीं है. इसके बजाय, यह पूछना सही सवाल है: कैननिकल नाम @@foo वाले रेपो के संदर्भ में, रेपो का दिखने वाला नाम @bar किस पर रिज़ॉल्व होता है? इसके अलावा, @@base की रेपो मैपिंग क्या है?

जिन लेबल में रिपॉज़िटरी के नाम साफ़ तौर पर दिखते हैं (@ से शुरू होने वाले), वे अलग-अलग चीज़ों के बारे में बता सकते हैं. यह इस बात पर निर्भर करता है कि उन्हें किस कॉन्टेक्स्ट से हल किया गया है. जब आपको कोई लेबल @bar//:baz दिखता है और आपको लगता है कि यह किसी और चीज़ की ओर इशारा कर रहा है, तो आपको सबसे पहले यह पता लगाना होगा कि कॉन्टेक्स्ट रिपो क्या है. उदाहरण के लिए, अगर लेबल, @@foo रिपो में मौजूद BUILD फ़ाइल में है, तो कॉन्टेक्स्ट रिपो @@foo है.

इसके बाद, माइग्रेशन गाइड में मौजूद "repository visibility" टेबल का इस्तेमाल करके यह पता लगाया जा सकता है कि कॉन्टेक्स्ट रिपो के हिसाब से, दिखने वाला नाम किस रिपो से जुड़ा है.

• अगर कॉन्टेक्स्ट रिपॉज़िटरी, मुख्य रिपॉज़िटरी (@@) है, तो:
  1. अगर bar, रूट मॉड्यूल की MODULE.bazel फ़ाइल से मिला कोई रीपो नाम है, तो @bar का मतलब वही होगा जो MODULE.bazel फ़ाइल में बताया गया है. यह नाम, bazel_dep, use_repo, module या use_repo_rule में से किसी एक के ज़रिए मिला होगा.
  2. इसके अलावा, अगर bar, WORKSPACE में तय किया गया कोई रेपो है (इसका मतलब है कि इसका कैननिकल नाम @@bar है), तो @bar, @@bar पर सेट हो जाता है.
  3. ऐसा न करने पर, @bar का नतीजा @@[unknown repo 'bar' requested from @@] जैसा कुछ होगा. इससे आखिर में गड़बड़ी होगी.
• अगर कॉन्टेक्स्ट रेपो, Bzlmod-world रेपो है (यानी कि यह नॉन-रूट Bazel मॉड्यूल से मेल खाती है या इसे मॉड्यूल एक्सटेंशन से जनरेट किया गया है), तो यह सिर्फ़ Bzlmod-world रेपो को देखेगी, न कि WORKSPACE-world रेपो को.
  • खास तौर पर, इसमें रूट मॉड्यूल में non_module_deps-like मॉड्यूल एक्सटेंशन में जोड़े गए सभी रीपो या रूट मॉड्यूल में use_repo_rule इंस्टैंटिएशन शामिल हैं.
• अगर कॉन्टेक्स्ट रिपो को WORKSPACE में तय किया गया है, तो:
  1. सबसे पहले, यह देखें कि कॉन्टेक्स्ट रिपो की परिभाषा में मैजिकल repo_mapping एट्रिब्यूट मौजूद है या नहीं. अगर ऐसा है, तो पहले मैपिंग देखें. जैसे, repo_mapping = {"@bar": "@baz"} के साथ तय किए गए किसी रेपो के लिए, हम नीचे दिए गए @baz को देखेंगे.
  2. अगर bar, रूट मॉड्यूल की MODULE.bazel फ़ाइल में दिया गया कोई रिपॉज़िटरी नाम है, तो @bar का मतलब वही होगा जो उस MODULE.bazel फ़ाइल में बताया गया है. (यह मुख्य रिपॉज़िटरी के मामले में आइटम 1 जैसा ही है.)
  3. ऐसा न होने पर, @bar की वैल्यू @@bar हो जाती है. ज़्यादातर मामलों में, यह WORKSPACE में तय किए गए bar repo की ओर इशारा करेगा. अगर ऐसा repo तय नहीं किया गया है, तो Bazel एक गड़बड़ी दिखाएगा.

ज़्यादा जानकारी के लिए:

• Bzlmod-world के दायरे में आने वाले रिपॉज़िटरी (मुख्य रिपॉज़िटरी को छोड़कर) को सिर्फ़ Bzlmod-world के दायरे में आने वाले रिपॉज़िटरी दिखेंगे.
• WORKSPACE-world रिपॉज़िटरी (मुख्य रिपॉज़िटरी भी शामिल है) सबसे पहले यह देखेंगी कि Bzlmod की दुनिया में रूट मॉड्यूल क्या तय करता है. इसके बाद, वे WORKSPACE-world रिपॉज़िटरी देखेंगी.

ध्यान दें कि Bazel कमांड लाइन में मौजूद लेबल (इनमें Starlark फ़्लैग, लेबल-टाइप वाले फ़्लैग की वैल्यू, और बिल्ड/टेस्ट टारगेट पैटर्न शामिल हैं) को कॉन्टेक्स्ट रेपो के तौर पर मुख्य रेपो के तौर पर माना जाता है.

अन्य

मैं ऑफ़लाइन बिल्ड को कैसे तैयार करूं और उसे कैसे चलाऊं?

रीपो को प्रीफ़ेच करने के लिए, bazel fetch कमांड का इस्तेमाल करें. सिर्फ़ रेपो @foo (मुख्य रेपो के कॉन्टेक्स्ट में हल किया गया, ऊपर दिया गया सवाल देखें) को फ़ेच करने के लिए, --repo फ़्लैग (जैसे, bazel fetch --repo @foo) का इस्तेमाल किया जा सकता है. इसके अलावा, @foo//:bar की सभी ट्रांज़िटिव डिपेंडेंसी को फ़ेच करने के लिए, टारगेट पैटर्न (जैसे, bazel fetch @foo//:bar) का इस्तेमाल किया जा सकता है. यह bazel build --nobuild @foo//:bar के बराबर है.

यह पक्का करने के लिए कि बिल्ड के दौरान कोई फ़ेच न हो, --nofetch का इस्तेमाल करें. ज़्यादा सटीक तरीके से कहें, तो इससे किसी भी नॉन-लोकल रिपॉज़िटरी के नियम को चलाने की कोशिश करने पर गड़बड़ी होती है.

अगर आपको लोकल लेवल पर जांच करने के लिए, रिपॉज़िटरी फ़ेच और उनमें बदलाव करना है, तो bazel vendor कमांड का इस्तेमाल करें.

मैं अपनी बिल्ड को इंटरनेट से कैसे अलग करूं?

यहां सार्वजनिक तौर पर ऐक्सेस किए जा सकने वाले इंटरनेट पर मौजूद कुछ ऐसी वेबसाइटों के बारे में बताया गया है जिन पर Bazel बिल्ड निर्भर करता है. साथ ही, संभावित रुकावटों से खुद को बचाने के तरीके बताए गए हैं. खास तौर पर, Bazel का इस्तेमाल करने वाले एंटरप्राइज़ के लिए.

• releases.bazel.build: Bazelisk, इस वेबसाइट से Bazel के रिलीज़ बाइनरी डाउनलोड करता है. Bazelisk को कॉन्फ़िगर किया जा सकता है, ताकि वह आपकी कंपनी के इंटरनल मिरर से डाउनलोड हो.
• bcr.bazel.build: Bazel, मॉड्यूल रिज़ॉल्यूशन के दौरान मॉड्यूल मेटाडेटा के लिए बीसीआर से सलाह लेता है. बीसीआर को मिरर किया जा सकता है. साथ ही, --registry फ़्लैग को सेट किया जा सकता है, ताकि बीसीआर के सर्वर इंफ़्रास्ट्रक्चर पर आपकी निर्भरता कम हो जाए. ज़्यादा जानकारी के लिए, अस्वीकरण देखें. इसके अलावा, यह पक्का किया जा सकता है कि आपकी MODULE.bazel.lock फ़ाइल अप-टू-डेट हो. साथ ही, डाउनलोड कैश मेमोरी (--repository_cache) के साथ अपने सीआई या डेवलपर मशीनों को सेट अप किया जा सकता है. अगर इसे सही तरीके से सेट अप किया जाता है, तो डाउनलोड कैश मेमोरी में, बिल्ड के लिए ज़रूरी सभी रजिस्ट्री फ़ाइलें शामिल होंगी. साथ ही, लॉकफ़ाइल में उनके चेकसम शामिल होंगे. इसके बाद, Bazel कैश मेमोरी में सेव किए गए नतीजों का इस्तेमाल करेगा. साथ ही, मॉड्यूल रिज़ॉल्यूशन के दौरान इंटरनेट ऐक्सेस करने से बचेगा.
• mirror.bazel.build और github.com: कई मॉड्यूल के सोर्स आर्काइव, इन दो वेबसाइटों पर होस्ट किए जाते हैं. सोर्स आर्काइव के लिए, कंपनी के अंदरूनी मिरर को सेट अप करें. साथ ही, Bazel को उनकी ओर ले जाने के लिए, --downloader_config या --module_mirrors का इस्तेमाल करें. इसके अलावा, पिछले बुलेट पॉइंट में बताई गई डाउनलोड की गई कैश मेमोरी को पहले से भरने से भी, Bazel को सोर्स आर्काइव के लिए इंटरनेट का इस्तेमाल करने से पूरी तरह से बचने में मदद मिलेगी.

मैं एचटीटीपी प्रॉक्सी का इस्तेमाल कैसे करूं?

Bazel, http_proxy और HTTPS_PROXY एनवायरमेंट वैरिएबल का इस्तेमाल करता है. इनका इस्तेमाल आम तौर पर curl जैसे अन्य प्रोग्राम भी करते हैं.

मैं डुअल-स्टैक IPv4/IPv6 सेटअप में, Bazel को IPv6 का इस्तेमाल करने के लिए कैसे कहूं?

सिर्फ़ IPv6 वाले कंप्यूटरों पर, Bazel बिना किसी बदलाव के डिपेंडेंसी डाउनलोड कर सकता है. हालांकि, ड्यूअल-स्टैक IPv4/IPv6 मशीनों पर Bazel, Java के जैसे ही नियमों का पालन करता है. अगर IPv4 चालू है, तो Bazel इसे प्राथमिकता देता है. कुछ स्थितियों में, जैसे कि जब IPv4 नेटवर्क बाहरी पतों को हल/पहुंच नहीं कर पाता है, तो इससे Network unreachable अपवाद हो सकते हैं और बिल्ड फ़ेल हो सकते हैं. ऐसे मामलों में, Bazel के डिफ़ॉल्ट व्यवहार को बदला जा सकता है. इसके लिए, java.net.preferIPv6Addresses=true system property का इस्तेमाल करके, IPv6 को प्राथमिकता दी जा सकती है. खास तौर पर, इस बारे में जानकारी मिलती है:

• --host_jvm_args=-Djava.net.preferIPv6Addresses=true startup option का इस्तेमाल करें. उदाहरण के लिए, अपनी .bazelrc फ़ाइल में यह लाइन जोड़ें:

  startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

• जब आपको ऐसे Java बिल्ड टारगेट चलाने हों जिन्हें इंटरनेट से कनेक्ट करने की ज़रूरत होती है (जैसे, इंटिग्रेशन टेस्ट के लिए), तब --jvmopt=-Djava.net.preferIPv6Addresses=true टूल फ़्लैग का इस्तेमाल करें. उदाहरण के लिए, अपनी .bazelrc फ़ाइल में यह शामिल करें:

  build --jvmopt=-Djava.net.preferIPv6Addresses

• अगर आपको डिपेंडेंसी के वर्शन की समस्या हल करने के लिए rules_jvm_external का इस्तेमाल करना है, तो COURSIER_OPTS एनवायरमेंट वैरिएबल में -Djava.net.preferIPv6Addresses=true भी जोड़ें. इससे Coursier के लिए JVM के विकल्प उपलब्ध कराए जा सकेंगे.

क्या रिमोट एक्ज़ीक्यूशन की मदद से, रिमोट तौर पर रेपो के नियमों को चलाया जा सकता है?

नहीं; या कम से कम, अभी तक नहीं. रिमोट एक्ज़ीक्यूशन सेवाओं का इस्तेमाल करने वाले लोगों को यह दिख सकता है कि रिपो के नियम अब भी स्थानीय तौर पर लागू होते हैं. उदाहरण के लिए, http_archive को पहले स्थानीय मशीन पर डाउनलोड किया जाएगा. इसके लिए, अगर लागू हो, तो किसी स्थानीय डाउनलोड कैश मेमोरी का इस्तेमाल किया जाएगा. इसके बाद, इसे एक्सट्रैक्ट किया जाएगा. इसके बाद, हर सोर्स फ़ाइल को रिमोट एक्ज़ीक्यूशन सेवा पर इनपुट फ़ाइल के तौर पर अपलोड किया जाएगा. यह सवाल पूछना स्वाभाविक है कि रिमोट एक्ज़ीक्यूशन सेवा, उस संग्रह को डाउनलोड और एक्सट्रैक्ट क्यों नहीं करती, ताकि बेकार राउंडट्रिप को सेव किया जा सके.

इसकी एक वजह यह है कि रेपो के नियम (और मॉड्यूल एक्सटेंशन) "स्क्रिप्ट" की तरह होते हैं, जिन्हें Bazel खुद चलाता है. रिमोट एक्ज़ीक्यूटर में Bazel इंस्टॉल होना ज़रूरी नहीं है.

एक और वजह यह है कि Bazel को अक्सर डाउनलोड किए गए और निकाले गए संग्रहों में मौजूद BUILD फ़ाइलों की ज़रूरत होती है, ताकि वह फ़ाइलों को लोड और उनका विश्लेषण कर सके. ये कार्रवाइयां स्थानीय तौर पर की जाती हैं.

इस समस्या को हल करने के लिए, शुरुआती तौर पर कुछ आइडिया मिले हैं. इनमें, रेपो के नियमों को फिर से बिल्ड करने के नियमों के तौर पर इस्तेमाल करना शामिल है. इससे, उन्हें रिमोटली चलाने की अनुमति मिल जाएगी. हालांकि, इससे आर्किटेक्चर से जुड़ी नई समस्याएं भी पैदा हो सकती हैं. उदाहरण के लिए, query कमांड को कार्रवाइयां चलाने की ज़रूरत पड़ सकती है, जिससे उनका डिज़ाइन जटिल हो जाएगा.

इस विषय पर पिछली चर्चा के बारे में ज़्यादा जानने के लिए, उन रिपॉज़िटरी के लिए Bazel का इस्तेमाल करने का तरीका जिन्हें फ़ेच करने के लिए Bazel की ज़रूरत होती है लेख पढ़ें.