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

इस पेज पर, 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 उदाहरण के तौर पर दिए गए नियम के रिपॉज़िटरी में, bazel-contrib/publish-to-bcr publish.yaml GitHub Action का इस्तेमाल किया जाता है. इससे रिलीज़ को BCR पर पब्लिश किया जा सकता है. इस कार्रवाई से, रिलीज़ वर्शन के साथ सोर्स संग्रह 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 फ़ाइल loads दूसरी फ़ाइल है, तो 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-जैसे मॉड्यूल एक्सटेंशन में जोड़े गए सभी रीपो या रूट मॉड्यूल में use_repo_rule इंस्टैंटिएशन शामिल हैं.
• अगर WORKSPACE में कॉन्टेक्स्ट रेपो तय किया गया है, तो:
  1. सबसे पहले, यह देखें कि कॉन्टेक्स्ट रिपो की परिभाषा में magical repo_mapping एट्रिब्यूट मौजूद है या नहीं. अगर ऐसा है, तो पहले मैपिंग करें. इसलिए, repo_mapping = {"@bar": "@baz"} के साथ तय किए गए किसी रेपो के लिए, हम यहां दिए गए @baz को देखेंगे.
  2. अगर bar, रूट मॉड्यूल की MODULE.bazel फ़ाइल में दिया गया कोई रिपॉज़िटरी नाम है, तो @bar का मतलब वही होगा जो उस MODULE.bazel फ़ाइल में बताया गया है. (यह मुख्य रिपॉज़िटरी के पहले आइटम जैसा ही है.)
  3. ऐसा न होने पर, @bar को @@bar के तौर पर सेट किया जाता है. ज़्यादातर मामलों में, यह WORKSPACE में तय किए गए bar repo की ओर इशारा करेगा. अगर ऐसा repo तय नहीं किया गया है, तो Bazel एक गड़बड़ी दिखाएगा.

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

• Bzlmod-world के रिपॉज़िटरी (मुख्य रिपॉज़िटरी को छोड़कर) को सिर्फ़ Bzlmod-world के रिपॉज़िटरी दिखेंगे.
• WORKSPACE-world के रिपॉज़िटरी (मुख्य रिपॉज़िटरी भी शामिल है) सबसे पहले यह देखेंगे कि Bzlmod world में रूट मॉड्यूल क्या तय करता है. इसके बाद, वे 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 अपवाद हो सकते हैं और बिल्ड फ़ेल हो सकते हैं. ऐसे मामलों में, java.net.preferIPv6Addresses=true system property का इस्तेमाल करके, Bazel के डिफ़ॉल्ट व्यवहार को बदला जा सकता है, ताकि वह 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 की ज़रूरत होती है लेख पढ़ें.