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

Nightly · 9.1 · 9.0 · 8.7 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

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

MODULE.bazel

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

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

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

आम तौर पर, यह प्रोसेस ऑटोमेटेड होती है. उदाहरण के लिए, rules-template के उदाहरण के तौर पर, नियम रिपॉज़िटरी, रिलीज़ को BCR पर पब्लिश करने के लिए, bazel-contrib/publish-to-bcr publish.yaml GitHub Action का इस्तेमाल करती है. यह ऐक्शन, रिलीज़ वर्शन के साथ सोर्स आर्काइव 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, load को क्यों सपोर्ट नहीं करता?

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

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

  • यह पक्का करना कि MODULE.bazel में दिया गया वर्शन, कहीं और सेव किए गए बिल्ड मेटाडेटा के साथ मेल खाता हो. उदाहरण के लिए, .bzl फ़ाइल में: इसे .bzl फ़ाइल में native.module_version तरीके का इस्तेमाल करके हासिल किया जा सकता है. यह फ़ाइल, BUILD फ़ाइल से लोड की जाती है.
  • बहुत बड़ी 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_repos का इस्तेमाल क्यों किया जाता है?

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

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 है.

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

  • अगर संदर्भ रिपो, मुख्य रिपो (@@) है, तो:
    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 एट्रिब्यूट है या नहीं. अगर ऐसा है, तो सबसे पहले मैपिंग देखें. इसलिए, a repo defined with repo_mapping = {"@bar": "@baz"}, के साथ तय की गई रिपो के लिए, हम नीचे @baz देखेंगे.
    2. अगर bar रूट मॉड्यूल की MODULE.bazel फ़ाइल से जोड़ा गया दिखने वाला रिपो नाम है, तो @bar उस रिपो को दिखाता है जिसके बारे में MODULE.bazel फ़ाइल दावा करती है. यह मुख्य रिपो के मामले में, पहले आइटम जैसा ही है.
    3. इसके अलावा, @bar @@bar को दिखाता है. ज़्यादातर मामलों में, यह WORKSPACE में तय की गई bar रिपो को दिखाता है. अगर ऐसी कोई रिपो तय नहीं की गई है, तो 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, मॉड्यूल रिज़ॉल्यूशन के दौरान, मॉड्यूल मेटाडेटा के लिए BCR से सलाह लेता है. BCR को मिरर किया जा सकता है और --registry फ़्लैग सेट किया जा सकता है, ताकि BCR की सेवा देने वाले इन्फ़्रास्ट्रक्चर पर आपकी डिपेंडेंसी खत्म हो जाए. ज़्यादा जानकारी के लिए, अस्वीकरण देखें. इसके अलावा, यह पक्का किया जा सकता है कि आपकी MODULE.bazel.lock फ़ाइल अप-टू-डेट हो. साथ ही, अपने सीआई या डेवलपर मशीनों को पहले से भरे गए डाउनलोड कैश (--repository_cache) के साथ सेट अप किया जा सकता है. अगर इसे सही तरीके से सेट अप किया जाता है, तो डाउनलोड कैश में, बिल्ड के लिए ज़रूरी सभी रजिस्ट्री फ़ाइलें मौजूद होंगी. साथ ही, लॉकफ़ाइल में उनके चेकसम मौजूद होंगे. इसके बाद, Bazel, कैश किए गए नतीजों का इस्तेमाल करेगा और मॉड्यूल रिज़ॉल्यूशन के दौरान, इंटरनेट ऐक्सेस से पूरी तरह से बचेगा.
  • mirror.bazel.build और github.com: कई मॉड्यूल के सोर्स आर्काइव, इन दोनों वेबसाइटों पर होस्ट किए जाते हैं. सोर्स आर्काइव के लिए, कंपनी के इंटरनल मिरर को सेट अप करने के बारे में सोचें. साथ ही, Bazel को उनकी ओर पॉइंट करने के लिए, --downloader_config या --module_mirrors में से किसी एक का इस्तेमाल करें. इसके अलावा, पिछले बुलेट पॉइंट में बताए गए पहले से भरे गए डाउनलोड कैश से भी Bazel को सोर्स आर्काइव के लिए इंटरनेट ऐक्सेस करने से पूरी तरह से बचने में मदद मिलेगी.

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

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

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

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

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

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

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

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

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

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