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

इस पेज पर, 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 फ़ाइल 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 Minimal Version Selection का इस्तेमाल करता है. जैसे, 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. सबसे पहले, यह देखें कि कॉन्टेक्स्ट रिपो की परिभाषा में मैजिकल 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 की दुनिया में रूट मॉड्यूल क्या तय करता है. इसके बाद, वे 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, 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 की ज़रूरत होती है लेख पढ़ें.