Bazel, बाहरी डिपेंडेंसी के साथ काम करता है. साथ ही, यह आपके बिल्ड में इस्तेमाल की गई ऐसी सोर्स फ़ाइलें (टेक्स्ट और बाइनरी), जिनका इस्तेमाल आपके फ़ाइल फ़ोल्डर में नहीं है. उदाहरण के लिए, वे GitHub repo, Maven आर्टफ़ैक्ट में होस्ट किए गए नियम या आपके मौजूदा फ़ाइल फ़ोल्डर के बाहर मौजूद आपकी लोकल मशीन पर डायरेक्ट्री हो सकती हैं.
Bazel 6.0 की तरह, Bazel से बाहरी डिपेंडेंसी मैनेज करने के दो तरीके हैं:
पारंपरिक, डेटा स्टोर करने की जगह पर फ़ोकस करने वाला WORKSPACE सिस्टम, और नया मॉड्यूल-फ़ोकस MODULE.bazel सिस्टम (कोड किए गए Bzlmod,
जिसे फ़्लैग फ़्लैग की मदद से चालू किया गया है). दो सिस्टम को एक साथ इस्तेमाल किया जा सकता है, लेकिन आने वाले समय में बेज़ल के हिसाब से Bzmodmod, व्यूल गाइड देखेंWORKSPACE--enable_bzlmod
यह दस्तावेज़, बेज़ल में एक्सटर्नल डिपेंडेंसी मैनेजमेंट से जुड़े कॉन्सेप्ट के बारे में बताता है. इसके बाद, दो सिस्टम में क्रम से लगाने के बारे में ज़्यादा जानकारी दी गई.
कॉन्सेप्ट
रिपॉज़िटरी
WORKSPACE या WORKSPACE.bazel फ़ाइल वाली डायरेक्ट्री, जिसमें बेज़ल बिल्ड में इस्तेमाल की जाने वाली सोर्स
फ़ाइलें होती हैं. इसे सिर्फ़ रिपो करके छोटा किया जाता है.
मुख्य डेटा स्टोर करने की जगह
वह रिपॉज़िटरी, जिसमें मौजूदा Bazel कमांड चलाया जा रहा है.
फ़ाइल फ़ोल्डर
सभी Bazel निर्देशों से शेयर किया गया एनवायरमेंट एक ही मुख्य डेटा स्टोर करने की जगह में चलता है.
ध्यान दें कि पहले "डेटा स्टोर करने की जगह" और "फ़ाइल फ़ोल्डर" को आपस में जोड़ दिया गया है. अब "फ़ाइल फ़ोल्डर" शब्द का इस्तेमाल मुख्य डेटा स्टोर करने की जगह को बताने के लिए किया गया है और कभी-कभी इसे "डेटा स्टोर करने की जगह" के समानार्थी के रूप में भी इस्तेमाल किया जाता है.
कैननिकल डेटा स्टोर करने की जगह का नाम
डेटा स्टोर करने की ऐसी जगह का कैननिकल नाम जिसे पता किया जा सकता है. फ़ाइल फ़ोल्डर के संदर्भ में, हर रिपॉज़िटरी का एक ही कैननिकल नाम होता है. रेपो
में एक टारगेट जिसका कैननिकल नाम canonical_name है उसे लेबल
@@canonical_name//pac/kage:target (डबल @ देखें) से लेबल किया जा सकता है.
मुख्य डेटा स्टोर करने की जगह पर हमेशा कैननिकल स्ट्रिंग के रूप में खाली स्ट्रिंग होती है.
डेटा स्टोर करने की जगह का नाम साफ़ तौर पर दिख रहा है
किसी रिपॉज़िटरी (डेटा स्टोर करने की जगह) में उस डेटा स्टोर करने वाले के नाम की जानकारी होती है.
इसे रेपो के "निकनेम" के तौर पर देखा जा सकता है. कैननिकल नाम के साथ रेपो
michael में रेपो के संदर्भ में साफ़ नाम mike हो सकता है, लेकिन रेपो के संदर्भ में यह साफ़ नाम mickey हो सकता है
bob.alice इस मामले में, michael के अंदर के किसी टारगेट को alice के संदर्भ में लेबल
@mike//pac/kage:target से ट्रैक किया जा सकता है (सिर्फ़ एक @ पर ध्यान दें).
इसके उलट, इसे डेटा स्टोर करने की जगह की मैपिंग के तौर पर समझा जा सकता है: हर रिपो में "एपोलिटरी रेपो नाम" से "कैननिकल रेपो नाम" तक मैपिंग होती है.
डेटा स्टोर करने से जुड़ा नियम
डेटा स्टोर करने की जगह की परिभाषाओं के लिए स्कीमा, जो Bazel को यह बताता है कि डेटा स्टोर करने की जगह को कैसे मिटाया जाता है. उदाहरण के लिए, आपका पेज "किसी खास यूआरएल से zip फ़ॉर्मैट में डाउनलोड हो सकता है" या "उसे निकाल सकता है". इसके अलावा, उसे "java_import टारगेट" के तौर पर उपलब्ध कराया जा सकता है या "किसी लोकल डायरेक्ट्री में सिम्युलेट किया जा सकता है". हर रिपो (रिपो) एक रिपो नियम के लिए तय होता है. यह सही आर्ग्युमेंट की संख्या के साथ होता है.
डेटा स्टोर करने की जगह से जुड़े अपने नियम लिखने के तरीके के बारे में ज़्यादा जानकारी के लिए, डेटा स्टोर करने के नियम देखें.
अब तक का सबसे सामान्य रिपो नियम http_archive है, जो किसी यूआरएल से कोई संग्रह डाउनलोड करता है और उसे निकालता है और local_repository होता है, जो स्थानीय डायरेक्ट्री को सिम्युलेट करता है जो पहले से ही बेज़ल रिपॉज़िटरी (डेटा स्टोर करने की जगह) है.
रिपॉज़िटरी फ़ेच करना
इससे जुड़े रेपो नियम को चलाकर, लोकल डिस्क पर रेपो उपलब्ध कराने की कार्रवाई. फ़ाइल फ़ोल्डर में बताए गए रिपॉज़िटरी, फ़ेच किए जाने से पहले लोकल डिस्क पर उपलब्ध नहीं होते.
आम तौर पर, बैज़ल सिर्फ़ रेपो फ़ेच करता है, जब उसे रेपो में से कुछ चाहिए होता है, लेकिन रेपो पहले से फ़ेच नहीं होता. अगर रेपो पहले ही फ़ेच किया जा चुका है, तो ज़रूरत होने पर बाज़ल सिर्फ़ इसे फिर से फ़ेच करता है.
डायरेक्ट्री का लेआउट
फ़ेच करने के बाद, रेपो, अपने कैननिकल नाम के तहत आउटपुट बेस में सबडायरेक्ट्री external में पाया जा सकता है.
कैननिकल नाम canonical_name की मदद से, कॉन्टेंट के बारे में जानने के लिए यहां दिया गया निर्देश देखें:
ls $(bazel info output_base)/external/ canonical_name
Bzlmod की मदद से एक्सटर्नल डिपेंडेंसी मैनेज करें
Bzlmod, नया एक्सपेरिमेंटल सबसिस्टम है, जो सीधे तौर पर रेपो परिभाषाओं के साथ काम नहीं करता. इसके बजाय, यह मॉड्यूल से डिपेंडेंसी ग्राफ़ बनाता है, ग्राफ़ के ऊपर एक्सटेंशन चलाता है, और उसी के मुताबिक डेटा में डेटा दिखाता है.
Bazen मॉड्यूल एक Bazel प्रोजेक्ट हो सकता है, जिसमें हर वर्शन के पास दूसरे मॉड्यूल के बारे में मेटाडेटा पब्लिश करने की अनुमति होती है. MODULE.bazel फ़ॉर्मैट में, WORKSPACE फ़ाइल के बगल में एक MODULE.bazel फ़ाइल होनी चाहिए. यह फ़ाइल, मॉड्यूल का मेनिफ़ेस्ट है, जो नाम, वर्शन, डिपेंडेंसी की सूची के साथ-साथ दूसरी जानकारी भी बताता है. यह एक बुनियादी उदाहरण है:
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
किसी मॉड्यूल को सिर्फ़ अपने डायरेक्ट डिपेंडेंसी की सूची बनानी होती है, जिसे Bzlmod Baze रजिस्ट्री में डिफ़ॉल्ट रूप से खोजता है. यह Bazel Central रजिस्ट्री में होती है. रजिस्ट्री, डिपेंडेंसी की MODULE.bazel फ़ाइलें उपलब्ध कराती है. इससे, बेज़ल वर्शन का रिज़ॉल्यूशन पूरा करने से पहले, पूरे ट्रांज़िटिव डिपेंडेंसी ग्राफ़ को खोज पाता है.
वर्शन रिज़ॉल्यूशन के बाद, जिसमें हर मॉड्यूल के लिए एक वर्शन चुना जाता है,
बेज़ल रजिस्ट्री को फिर से सलाह देती हैं.
इससे वे हर मॉड्यूल के लिए रेपो तय करने का तरीका जान सकते हैं. ज़्यादातर मामलों में, यह http_archive का इस्तेमाल करके बनाया जाता है.
मॉड्यूल से टैग नाम के डेटा के कस्टमाइज़ किए गए हिस्से भी तय किए जा सकते हैं, जिन्हें मॉड्यूल रिज़ॉल्यूशन के बाद मॉड्यूल एक्सटेंशन से इस्तेमाल किया जाता है. ऐसा अतिरिक्त डेटा को तय करने के लिए किया जाता है. इन एक्सटेंशन में, डेटा सेव करने से जुड़े नियमों से मिलती-जुलती सुविधाएं होती हैं. इनकी मदद से, I/O फ़ाइल भेजे जा सकते हैं और नेटवर्क से जुड़े अनुरोध भेजे जा सकते हैं. दूसरी चीज़ों के अलावा, वे Bazel को अन्य पैकेज मैनेजमेंट सिस्टम के साथ इंटरैक्ट करने की भी अनुमति देते हैं. साथ ही, Bazel मॉड्यूल से बने डिपेंडेंसी ग्राफ़ को भी ध्यान में रखते हैं.
Bzlmod पर बाहरी लिंक
- bazelbuild/examples में Bzlmod के इस्तेमाल के उदाहरण
- Bazen की बाहरी डिपेंडेंसी ओवरहॉल (मूल Bzlmod डिज़ाइन दस्तावेज़)
- Bzlmod पर 2021 के अवॉर्ड पर चर्चा
- Bzlmod पर बाज़ल कम्यूनिटी डे पर बातचीत
WORKSPACE की मदद से डेटा स्टोर करने की जगह तय करें
ऐतिहासिक तौर पर, आप WORKSPACE (या WORKSPACE.bazel) फ़ाइल में डेटा स्टोर करने की जगह तय करके, डिपेंडेंसी को मैनेज कर सकते हैं. इस फ़ाइल का सिंटैक्स
BUILD फ़ाइलों जैसा ही है. इसमें बिल्ड नियमों के बजाय रेपो नियम लागू किए गए हैं.
नीचे दिए गए स्निपेट में, WORKSPACE फ़ाइल में http_archive रिपो नियम का इस्तेमाल
करने का उदाहरण दिया गया है:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "foo",
urls = ["https://example.com/foo.zip"],
sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)
इस स्निपेट में ऐसे रेपो के बारे में बताया गया है जिसका कैननिकल नाम foo है. WORKSPACE
सिस्टम में, डिफ़ॉल्ट रूप से रेपो का कैननिकल नाम, बाकी सभी डेटा स्टोर करने की जगहों
पर दिखने वाला कैननिकल नाम भी होता है.
WORKSPACE फ़ाइलों में उपलब्ध फ़ंक्शन की पूरी सूची देखें.
WORKSPACE सिस्टम की कमियां
WORKSPACE सिस्टम के लागू होने के बाद से, सालों तक उपयोगकर्ताओं ने कई समस्याओं की रिपोर्ट की. इनमें ये शामिल हैं:
- बैज़ल किसी भी डिपेंडेंसी की
WORKSPACEफ़ाइलों का मूल्यांकन नहीं करता. इसलिए, सभी डिपेंडेंसी डिपेंडेंसी, मुख्य रिपो कीWORKSPACEफ़ाइल में बताई जानी चाहिए. इसके साथ ही, डायरेक्ट डिपेंडेंसी भी ज़रूरी है. - इस पर काम करने के लिए, प्रोजेक्ट ने "deps.bzl" पैटर्न को अपनाया है. इसमें, एक मैक्रो तय किया जाता है, जो एक से ज़्यादा रिपॉज़िटरी तय करता है. साथ ही, उपयोगकर्ताओं से उनकी
WORKSPACEफ़ाइलों में इस मैक्रो को कॉल करने के लिए कहता है.- इसकी अपनी समस्याएं हैं: मैक्रो
loadअन्य.bzlफ़ाइलें नहीं बना सकते, इसलिए इन प्रोजेक्ट को "डेप" मैक्रो में अपनी ट्रांज़िटिविटी डिपेंडेंसी तय करनी होगी या उपयोगकर्ता को कई लेयर वाले "डेप" मैक्रो में कॉल करने के लिए, इस समस्या पर काम करना होगा. - Bazel, क्रम से
WORKSPACEफ़ाइल की जांच करता है. इसके अलावा, डिपेंडेंसी, यूआरएल के साथhttp_archiveका इस्तेमाल करके तय की जाती है. इसके लिए, किसी वर्शन की जानकारी नहीं दी जाती है. इसका मतलब है कि हीरे पर निर्भरता के मामले में वर्शन रिज़ॉल्यूशन लागू करने का कोई भरोसेमंद तरीका नहीं है (A,BऔरCपर निर्भर करता है;BऔरCदोनोंDके अलग-अलग वर्शन पर निर्भर करते हैं).
- इसकी अपनी समस्याएं हैं: मैक्रो
WORKSPACE में आने वाली कमियों की वजह से, Bzlmod लेगसी WorkSPACE सिस्टम को आने वाले समय में Bazel की रिलीज़ में बदल देगा. कृपया Bzlmod पर माइग्रेट करने के तरीके के बारे में Bzlmod माइग्रेशन गाइड पढ़ें.