Bazel को आपकी ज़रूरतों के हिसाब से लगातार बेहतर बनाया जा रहा है. इसलिए, हम 2025 के लिए अपने रोडमैप का अपडेट शेयर करना चाहते हैं.
हम Bazel 9.0 लंबे समय तक सहायता (एलटीएस) को 2025 के आखिर में आपके लिए उपलब्ध कराएंगे.
Bzlmod पर पूरी तरह से ट्रांज़िशन करना
Bazel 7 के बाद से, Bzlmod, Bazel में स्टैंडर्ड एक्सटर्नल डिपेंडेंसी सिस्टम है. इसने लेगसी WORKSPACE सिस्टम की जगह ले ली है. मार्च 2025 तक, Bazel Central Registry में 650 से ज़्यादा मॉड्यूल होस्ट किए गए हैं.
Bazel 9 में, हम WORKSPACE फ़ंक्शन को पूरी तरह से हटा देंगे. साथ ही, Bazel में बाहरी डिपेंडेंसी जोड़ने का सिर्फ़ एक तरीका होगा, यानी कि Bzlmod. हम माइग्रेशन की लागत को कम करने के लिए, माइग्रेशन से जुड़ी गाइड और टूल को और बेहतर बनाने पर फ़ोकस करेंगे.
इसके अलावा, हमारा मकसद गार्बेज कलेक्शन के साथ बेहतर शेयर की गई रिपॉज़िटरी कैश (देखें #12227) को लागू करना है. साथ ही, इसे Bazel 8 पर वापस ले जाया जा सकता है. Bazel Central Registry, SLSA attestations की पुष्टि करने में भी मदद करेगी.
Android, C++, Java, Python, और Proto के नियमों को माइग्रेट करना
Bazel 8 में, हमने Android, Java, Python, और Proto के लिए Bazel कोडबेस से Starlark नियमों में माइग्रेट किया है. माइग्रेशन को आसान बनाने के लिए, हमने Bazel में अपने-आप लोड होने की सुविधाएं लागू की हैं. इन्हें --incompatible_autoload_externally और --incompatible_disable_autoloads_in_main_repo फ़्लैग से कंट्रोल किया जा सकता है.
Bazel 9 में, हमारा लक्ष्य डिफ़ॉल्ट रूप से ऑटोलोड को बंद करना है. साथ ही, हर प्रोजेक्ट के लिए यह ज़रूरी है कि वह BUILD फ़ाइलों में ज़रूरी नियमों को साफ़ तौर पर लोड करे.
हम C++ भाषा के लिए उपलब्ध ज़्यादातर सुविधाओं को Starlark में फिर से लिखेंगे. साथ ही, इसे Bazel बाइनरी से अलग करके /rules_cc रिपॉज़िटरी में ले जाएंगे. यह आखिरी ऐसी मुख्य भाषा है जिसके लिए अब भी Bazel में सहायता उपलब्ध है.
हम C++, Java, और Proto नियमों के लिए यूनिट टेस्ट को Starlark में पोर्ट कर रहे हैं. साथ ही, हम उन्हें लागू करने के बगल में मौजूद रिपॉज़िटरी में ले जा रहे हैं, ताकि नियम बनाने वालों के लिए काम को आसान बनाया जा सके.
Starlark में किए गए सुधार
Bazel में, सिंबॉलिक मैक्रो का आकलन देर से करने की सुविधा होगी. इसका मतलब है कि अगर टारगेट के लिए अनुरोध नहीं किया जाता है, तो सिंबॉलिक मैक्रो नहीं चलेगा. इससे बहुत बड़े पैकेज की परफ़ॉर्मेंस बेहतर होती है.
Starlark में एक्सपेरिमेंट के तौर पर टाइप सिस्टम उपलब्ध होगा. यह Python के टाइप एनोटेशन की तरह होगा. हमें उम्मीद है कि Bazel 9 लॉन्च होने के बाद, टाइप सिस्टम स्थिर हो जाएगा.
कॉन्फ़िगर करने की सुविधा
हमारा मुख्य मकसद, बिल्ड फ़्लैग की लागत को कम करना और भ्रम को दूर करना है.
हम प्रोजेक्ट कॉन्फ़िगरेशन के नए मॉडल पर एक्सपेरिमेंट कर रहे हैं. इसमें उपयोगकर्ताओं को यह जानने की ज़रूरत नहीं होगी कि किस बिल्ड और टेस्ट फ़्लैग को कहां सेट करना है. इसलिए, $ bazel test //foo, foo के प्रोजेक्ट की नीति के आधार पर सही फ़्लैग अपने-आप सेट कर देता है. ऐसा हो सकता है कि यह सुविधा Android 9.0 में एक्सपेरिमेंट के तौर पर उपलब्ध रहे. हालांकि, इस बारे में सुझाव/राय देने या शिकायत करने का स्वागत है.
फ़्लैग स्कोपिंग की मदद से, प्रोजेक्ट की सीमाओं से बाहर जाने पर Starlark फ़्लैग हटाए जा सकते हैं. इससे, ट्रांज़िटिव डिपेंडेंसी पर कैश मेमोरी काम करना बंद नहीं करती. इससे ट्रांज़िशन का इस्तेमाल करने वाले बिल्ड को कम कीमत पर और तेज़ी से बनाया जा सकता है. यहां एक उदाहरण दिया गया है. यहां हम इस आइडिया को आगे बढ़ा रहे हैं, ताकि यह कंट्रोल किया जा सके कि कौनसे फ़्लैग exec कॉन्फ़िगरेशन में शामिल किए जाएं. साथ ही, हम कस्टम स्टार्लार्क जैसे ज़्यादा फ़्लेक्सिबल सपोर्ट पर विचार कर रहे हैं, ताकि यह तय किया जा सके कि किन डिपेंडेंसी एज को फ़्लैग शामिल करने की अनुमति दी जानी चाहिए.
हम Bazel से बिल्ट-इन भाषा के फ़्लैग को Starlark में ले जाने की कोशिश कर रहे हैं. इससे, वे फ़्लैग संबंधित नियम की परिभाषाओं के साथ काम कर पाएंगे.
रिमोट एक्ज़ीक्यूशन में सुधार
हम एसिंक्रोनस एक्ज़ीक्यूशन के लिए सहायता जोड़ने का प्लान बना रहे हैं. इससे पैरललिज़्म को बढ़ाकर, रिमोट एक्ज़ीक्यूशन को तेज़ किया जा सकेगा.
रोडमैप से जुड़े अपडेट पाने और प्लान की गई सुविधाओं के बारे में चर्चा करने के लिए, slack.bazel.build पर जाकर, कम्यूनिटी के Slack सर्वर से जुड़ें.
इस रोडमैप का मकसद, कम्यूनिटी को Bazel 9.0 के लिए टीम के इरादों के बारे में जानकारी देना है. डेवलपर और ग्राहक से मिले सुझाव या नई मार्केट ऑपर्च्यूनिटी के आधार पर, प्राथमिकताओं में बदलाव किया जा सकता है.