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

इस पेज पर, 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 की रजिस्ट्री देखें.

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

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

मुझे कंपैटिबिलिटी लेवल कब बढ़ाना चाहिए?

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" table का इस्तेमाल करके यह पता लगाया जा सकता है कि कॉन्टेक्स्ट रिपो के हिसाब से, दिखने वाला नाम किस रिपो से जुड़ा है.

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