इस पेज पर, डेटा स्टोर करने के नियम बनाने का तरीका बताया गया है. साथ ही, ज़्यादा जानकारी के लिए उदाहरण भी दिए गए हैं.
एक्सटर्नल रिपॉज़िटरी एक ऐसा नियम है जिसका इस्तेमाल सिर्फ़ WORKSPACE फ़ाइल में किया जा सकता है. साथ ही, यह बेज़ल की लोडिंग फ़ेज़ पर नॉन-हर्मेटिक ऑपरेशन की सुविधा देता है. डेटा स्टोर करने की जगह का हर नियम, अपनी BUILD फ़ाइलों और आर्टफ़ैक्ट के साथ अपना फ़ाइल फ़ोल्डर बनाता है. इनका इस्तेमाल तीसरे पक्ष की लाइब्रेरी (जैसे कि Maven के पैकेज की गई लाइब्रेरी) पर निर्भर रहने के लिए किया जा सकता है. साथ ही, इनका इस्तेमाल होस्ट Basel के चल रहे होस्ट के लिए खास BUILD फ़ाइलों को जनरेट करने के लिए भी किया जा सकता है.
डेटा स्टोर करने के लिए नियम बनाना
.bzl फ़ाइल में, डेटा स्टोर करने का नया नियम बनाने और उसे ग्लोबल वैरिएबल में सेव करने के लिए, repository_rule फ़ंक्शन का इस्तेमाल करें.
कस्टम रिपॉज़िटरी के नियम का इस्तेमाल, नेटिव रिपॉज़िटरी के नियम की तरह ही किया जा सकता है. इसमें एक ज़रूरी name एट्रिब्यूट है और इसकी बिल्ड फ़ाइलों में मौजूद हर टारगेट को @<name>//package:target कहा जा सकता है, जहां <name>, name एट्रिब्यूट की वैल्यू है.
नियम तब लोड होता है, जब आपने साफ़ तौर पर इसे बनाया हो या यह बिल्ड पर डिपेंडेंसी हो. इस मामले में, Basel अपने implementation फ़ंक्शन को एक्ज़ीक्यूट करेगा. इस फ़ंक्शन में, रिपॉज़िटरी (डेटा स्टोर करने की जगह), उसका कॉन्टेंट, और BUILD फ़ाइलें बनाने का तरीका बताया गया है.
विशेषताएं
एट्रिब्यूट, नियम के ऐसे तर्क होते हैं जिन्हें attrs नियम के तर्क के लिए, लिखवाने के तौर पर पास किया जाता है.
डेटा स्टोर करने का नियम तय करने पर, एट्रिब्यूट और उनके टाइप की जानकारी दी जाती है. url और sha256 एट्रिब्यूट को स्ट्रिंग के तौर पर परिभाषित करने वाला उदाहरण:
local_repository = repository_rule(
implementation=_impl,
local=True,
attrs={
"url": attr.string(mandatory=True)
"sha256": attr.string(mandatory=True)
}
)
लागू करने वाले फ़ंक्शन में किसी एट्रिब्यूट को ऐक्सेस करने के लिए, repository_ctx.attr.<attribute_name> का इस्तेमाल करें:
def _impl(repository_ctx):
url = repository_ctx.attr.url
checksum = repository_ctx.attr.sha256
सभी repository_rule में, सीधे तौर पर तय किए गए एट्रिब्यूट होते हैं (जैसे कि बिल्ड
नियम). इसके लिए, दो इंप्लिसिट एट्रिब्यूट हैं: name (बिल्ड रूल की तरह) और
repo_mapping. डेटा स्टोर करने की जगह के नियम के नाम को repository_ctx.name से ऐक्सेस किया जा सकता है. repo_mapping का मतलब वही है जो
नेटिव डेटा स्टोर करने की जगह के नियमों
local_repository और
new_local_repository में है.
अगर किसी एट्रिब्यूट का नाम _ से शुरू होता है, तो यह 'निजी' के तौर पर सेट होता है और उपयोगकर्ता इसे सेट नहीं कर सकते.
लागू करने का फ़ंक्शन
डेटा स्टोर करने के हर नियम के लिए, implementation फ़ंक्शन ज़रूरी होता है. इसमें नियम का असल लॉजिक होता है और इसे लोड करने के चरण में पूरी तरह से लागू किया जाता है.
इस फ़ंक्शन में सिर्फ़ एक इनपुट पैरामीटर, repository_ctx है. फ़ंक्शन या तो None दिखाता है, ताकि यह बताया जा सके कि तय किए गए पैरामीटर के आधार पर नियम को फिर से बनाया जा सकता है या उस नियम के लिए पैरामीटर के सेट के साथ एक ऐसा लिखवाने की सुविधा मिलती है जो उस नियम को उसी रिपॉज़िटरी को जनरेट करने वाले फिर से जनरेट किए जा सकने वाले नियम में बदल देता है. उदाहरण के लिए,
किसी नियम के लिए जो GitHub रिपॉज़िटरी को ट्रैक करता है, जिसका मतलब
मूल रूप से तय की गई फ़्लोटिंग ब्रांच के बजाय
कोई खास कमिट आइडेंटिफ़ायर देना होगा.
इनपुट पैरामीटर repository_ctx का इस्तेमाल एट्रिब्यूट वैल्यू और नॉन-हर्मेटिक फ़ंक्शन को ऐक्सेस करने के लिए किया जा सकता है. इन फ़ंक्शन में बाइनरी ढूंढना, बाइनरी चलाना, रिपॉज़िटरी में फ़ाइल बनाना या इंटरनेट से कोई फ़ाइल डाउनलोड करना शामिल है. ज़्यादा जानकारी के लिए लाइब्रेरी देखें. उदाहरण:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
लागू करने का फ़ंक्शन कब चलाया जाता है?
डेटा स्टोर करने की जगह को लागू करने का फ़ंक्शन तब लागू होता है, जब Basel को उस डेटा स्टोर करने की जगह से किसी टारगेट की ज़रूरत हो. उदाहरण के लिए, जब कोई दूसरा टारगेट (किसी अन्य डेटा स्टोर करने की जगह में) उस पर निर्भर हो या जब उसका नाम कमांड लाइन पर बताया गया हो. इसके बाद, लागू करने वाले फ़ंक्शन को फ़ाइल सिस्टम में रिपॉज़िटरी बनाना होता है. इसे रिपॉज़िटरी को "फ़ेच करना" कहा जाता है.
सामान्य टारगेट के उलट, जब डेटा में कोई बदलाव होता है, तो डेटा स्टोर करने की जगह को फिर से फ़ेच करना ज़रूरी नहीं होता. ऐसा इसलिए है, क्योंकि ऐसी चीज़ें हैं जिनकी वजह से Baze बदलावों का पता नहीं चल पाता या जिसकी वजह से हर बिल्ड के लिए बहुत ज़्यादा ओवरहेड होता है (उदाहरण के लिए, नेटवर्क से फ़ेच की जाने वाली चीज़ें). इसलिए, डेटा स्टोर करने की जगह को सिर्फ़ तब फिर से फ़ेच किया जाता है, जब इनमें से कोई एक चीज़ बदलती है:
WORKSPACEफ़ाइल में, डेटा स्टोर करने की जगह के एलान में पास किए गए पैरामीटर.- Starlark कोड में, रिपॉज़िटरी को लागू करना शामिल है.
- किसी भी एनवायरमेंट वैरिएबल की वैल्यू,
repository_ruleकेenvironएट्रिब्यूट के साथ तय की जाती है. इन एनवायरमेंट वैरिएबल की वैल्यू को कमांड लाइन पर,--action_envफ़्लैग के साथ हार्ड-वायर किया जा सकता है. हालांकि, यह फ़्लैग बिल्ड के हर ऐक्शन को अमान्य कर देगा. read(),execute()औरrepository_ctxके मिलते-जुलते तरीकों को पास की गई किसी भी फ़ाइल का कॉन्टेंट, जिसे लेबल से बताया जाता है (उदाहरण के लिए,//mypkg:label.txt, लेकिनmypkg/label.txtनहीं)bazel syncशुरू होने पर.
repository_rule के दो पैरामीटर होते हैं, जो यह कंट्रोल करते हैं कि डेटा स्टोर करने की जगहों को फिर से कब फ़ेच किया जाता है:
- अगर
configureफ़्लैग सेट है, तो रिपॉज़िटरी कोbazel syncपर सिर्फ़ तब फिर से फ़ेच किया जाता है, जब--configureपैरामीटर को उस पर पास किया जाता है (अगर एट्रिब्यूट को सेट नहीं किया गया है, तो इस निर्देश की वजह से उसे फिर से फ़ेच नहीं किया जाएगा) अगर
localफ़्लैग सेट किया गया है, तो ऊपर दिए गए मामलों के अलावा, डेटा स्टोर करने की जगह को तब भी फिर से फ़ेच किया जाता है, जब बेज़ल सर्वर के रीस्टार्ट होने पर या रिपॉज़िटरी के एलान पर असर डालने वाली किसी फ़ाइल (जैसे,WORKSPACEफ़ाइल या वह फ़ाइल लोड होती है) में बदलाव होता है. इस बात से कोई फ़र्क़ नहीं पड़ता कि इन बदलावों की वजह से, डेटा स्टोर करने की जगह के एलान या उसके कोड में बदलाव हुआ है या नहीं.ऐसे मामलों में, डेटा स्टोर करने की गैर-स्थानीय जगहों को फिर से नहीं लाया जाता. ऐसा इसलिए होता है, क्योंकि यह माना जाता है कि डेटा स्टोर करने की ये जगहें, नेटवर्क से जुड़ी जानकारी उपलब्ध कराती हैं या फिर इनके लिए महंगी हैं.
लागू करने वाले फ़ंक्शन को रीस्टार्ट करना
अगर किसी डिपेंडेंसी का अनुरोध किया गया है और उसके पास मौजूद नहीं है, तो डेटा स्टोर करने की जगह को फ़ेच करने के दौरान, लागू करने वाले फ़ंक्शन को फिर से शुरू किया जा सकता है. ऐसे मामले में, लागू करने वाला फ़ंक्शन बंद हो जाएगा और जो डिपेंडेंसी मौजूद नहीं है उसे ठीक कर दिया जाएगा. साथ ही, डिपेंडेंसी के ठीक होने के बाद, फ़ंक्शन को फिर से लागू किया जाएगा. ग़ैर-ज़रूरी बार रीस्टार्ट होने से बचने के लिए (जो महंगा होता है, क्योंकि नेटवर्क ऐक्सेस को दोहराना पड़ सकता है), लेबल के आर्ग्युमेंट प्रीफ़ेच किए जाते हैं. हालांकि, इसके लिए यह ज़रूरी है कि लेबल वाले सभी आर्ग्युमेंट को किसी मौजूदा फ़ाइल में हल किया जा सके. ध्यान दें कि सिर्फ़ फ़ंक्शन को एक्ज़ीक्यूट करने के दौरान बनाए गए स्ट्रिंग या लेबल में से पाथ को ठीक करने पर, रीस्टार्ट भी हो सकता है.
डेटा स्टोर करने की बाहरी जगहों को फिर से फ़ेच करना
कभी-कभी, बाहरी डेटा स्टोर करने की जगह अपनी परिभाषा या डिपेंडेंसी में किसी भी बदलाव के बिना पुरानी हो सकती है. उदाहरण के लिए, डेटा स्टोर करने की जगह को फ़ेच करने वाला सोर्स, तीसरे पक्ष के डेटा स्टोर करने की जगह की किसी ब्रांच को फ़ॉलो कर सकता है और उस ब्रांच में नई कमिट की सुविधा उपलब्ध है. ऐसे मामले में, बेज़ल को बिना किसी शर्त के सभी बाहरी डेटा स्टोर करने की जगहों को फिर से फ़ेच करने के लिए कहा जा सकता है. इसके लिए, आपको bazel sync पर कॉल करना होगा.
इसके अलावा, कुछ नियम लोकल मशीन की जांच करते हैं और अगर लोकल मशीन को अपग्रेड किया गया था, तो
हो सकता है कि नियम पुराने हो जाएं. यहां, Baज़ल को सिर्फ़ उन बाहरी डेटा स्टोर करने की जगहों को फिर से फ़ेच करने के लिए कहा जा सकता है जहां
repository_rule
परिभाषा में configure एट्रिब्यूट सेट है. इसके लिए, bazel sync --configure का इस्तेमाल करें.
उदाहरण
C++ अपने-आप कॉन्फ़िगर होने वाला टूलचेन: यह रिपॉज़िटरी के नियम का इस्तेमाल करता है. इससे बज़ल के लिए अपने-आप C++ कॉन्फ़िगरेशन फ़ाइलें बन जाती हैं. इसके लिए, वह लोकल C++ कंपाइलर, एनवायरमेंट, और C++ कंपाइलर के साथ काम करने वाले फ़्लैग की खोज करता है.
Go रिपॉज़िटरी में, Go नियमों का इस्तेमाल करने के लिए ज़रूरी डिपेंडेंसी की सूची तय करने के लिए, कई
repository_ruleका इस्तेमाल किया जाता है.rules_jvm_external डिफ़ॉल्ट रूप से,
@mavenनाम का एक बाहरी डेटा स्टोर करता है. यह ट्रांज़िटिव डिपेंडेंसी ट्री में हर Maven आर्टफ़ैक्ट के लिए, बिल्ड टारगेट जनरेट करता है.