इस पेज पर, डेटा स्टोर करने के नियम बनाने का तरीका बताया गया है. साथ ही, देखें.
बाहरी रिपॉज़िटरी एक ऐसा नियम है जिसका इस्तेमाल सिर्फ़ WORKSPACE फ़ाइल में किया जा सकता है. साथ ही, यह Bazel के लोडिंग फ़ेज़ में नॉन-हर्मेटिक ऑपरेशन को चालू करता है. हर एक्सटर्नल रिपॉज़िटरी नियम अपना फ़ाइल फ़ोल्डर बनाता है, जिसमें
BUILD फ़ाइलों और आर्टफ़ैक्ट का मालिकाना हक है. इनका इस्तेमाल, तीसरे पक्ष की लाइब्रेरी (जैसे, मेवन पैकेज वाली लाइब्रेरी) पर निर्भर करने के लिए किया जा सकता है. साथ ही, इनका इस्तेमाल उस होस्ट के लिए खास BUILD फ़ाइलें जनरेट करने के लिए भी किया जा सकता है जिस पर Bazel चल रहा है.
रिपॉज़िटरी का नियम बनाना
.bzl फ़ाइल में, repository_rule फ़ंक्शन का इस्तेमाल करके, नया रिपॉज़िटरी नियम बनाएं और उसे ग्लोबल वैरिएबल में सेव करें.
कस्टम रिपॉज़िटरी नियम का इस्तेमाल, नेटिव रिपॉज़िटरी नियम की तरह ही किया जा सकता है. यह
एक ज़रूरी name एट्रिब्यूट है और हर टारगेट उसकी बिल्ड फ़ाइलों में मौजूद है
को @<name>//package:target कहा जा सकता है, जहां <name>
name एट्रिब्यूट की वैल्यू सबमिट करें.
नियम तब लोड होता है, जब आप इसे साफ़ तौर पर बनाते हैं या अगर यह
बिल्ड. इस मामले में, Bazel अपना implementation फ़ंक्शन लागू करेगा. इस फ़ंक्शन में, रिपॉज़िटरी, उसका कॉन्टेंट, और BUILD फ़ाइलें बनाने का तरीका बताया गया है.
विशेषताएं
एट्रिब्यूट, नियम के ऐसे तर्क होते हैं जिन्हें attrs नियम के तर्क के लिए, लिखवाने के तौर पर पास किया जाता है.
विशेषताएं और उनके प्रकार तब बताए जाते हैं, जब आप
डेटा स्टोर करने की जगह का नियम है. url और sha256 एट्रिब्यूट की जानकारी देने वाला उदाहरण
strings:
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
किसी खास पैरामीटर का इस्तेमाल करें या उस नियम के लिए पैरामीटर के सेट के साथ ऐसा डिक्शनरी देखें जिसमें
उस नियम को उसी डेटा संग्रह स्थान को जनरेट करने वाले फिर से जनरेट किए जाने वाले नियम में बदल देगा. इसके लिए
उदाहरण के लिए, एक git रिपॉज़िटरी को ट्रैक करने वाले नियम का मतलब
किसी फ़्लोटिंग ब्रांच के बजाय, खास तौर पर जनरेट किया गया आइडेंटिफ़ायर
बताया गया है.
इनपुट पैरामीटर repository_ctx का इस्तेमाल, एट्रिब्यूट की वैल्यू और ऐसे फ़ंक्शन को ऐक्सेस करने के लिए किया जा सकता है जो पूरी तरह से सुरक्षित नहीं होते. जैसे, कोई बाइनरी ढूंढना, बाइनरी को चलाना, रिपॉज़िटरी में कोई फ़ाइल बनाना या इंटरनेट से कोई फ़ाइल डाउनलोड करना. ज़्यादा जानकारी के लिए, लाइब्रेरी देखें. उदाहरण:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
लागू करने का फ़ंक्शन कब चलाया जाता है?
किसी रिपॉज़िटरी का लागू करने वाला फ़ंक्शन तब लागू होता है, जब Bazel को उस रिपॉज़िटरी से किसी टारगेट की ज़रूरत होती है. उदाहरण के लिए, जब कोई दूसरा टारगेट (किसी दूसरी रिपॉज़िटरी में) उस पर निर्भर होता है या कमांड लाइन में उसका ज़िक्र किया जाता है. इसके बाद, लागू करने वाले फ़ंक्शन को फ़ाइल सिस्टम में रिपॉज़िटरी बनानी होगी. इसे रिपॉज़िटरी को "फ़ेच करना" कहा जाता है.
नियमित लक्ष्यों के विपरीत, डेटा स्टोर करने की जगहों को तब फिर से फ़ेच नहीं किया जाता, जब कुछ ऐसे बदलाव करते हैं, जिनसे रिपॉज़िटरी अलग हो जाएगी. यह है क्योंकि बेज़ल कुछ चीज़ों में हुए बदलावों का पता नहीं लगा पाते या ऐसा करने से वे हर बिल्ड पर बहुत ज़्यादा ओवरहेड करते हैं. उदाहरण के लिए, फ़ेच की जाने वाली चीज़ें नेटवर्क से). इसलिए, डेटा स्टोर करने की जगह को सिर्फ़ तब फिर से फ़ेच किया जाता है, जब इन चीज़ों में बदलाव होता है:
WORKSPACEफ़ाइल में, डेटा स्टोर करने की जगह के एलान के लिए पास किए गए पैरामीटर.- Starlark कोड में, रिपॉज़िटरी को लागू करना शामिल है.
repository_ctxकेgetenv()तरीके में पास किए गए किसी भी एनवायरमेंट वैरिएबल की वैल्यू याrepository_ruleकेenvironएट्रिब्यूट के साथ एलान की गई वैल्यू. वैल्यू इन एनवायरमेंट वैरिएबल को कमांड लाइन पर हार्ड-तार वाले--repo_envफ़्लैग करें.read(),execute(), औरrepository_ctxके मिलते-जुलते तरीकों में पास की गई किसी भी फ़ाइल का कॉन्टेंट, जिसे किसी लेबल से रेफ़र किया जाता है (उदाहरण के लिए,//mypkg:label.txt, लेकिनmypkg/label.txtनहीं)- जब
bazel syncको लागू किया जाता है.
repository_rule के दो पैरामीटर हैं, जो डेटा स्टोर करने की जगह को कब कंट्रोल करते हैं
फिर से फ़ेच किए जाते हैं:
- अगर
configureफ़्लैग सेट किया गया है, तो डेटा स्टोर करने की जगह को सिर्फ़ फिर से फ़ेच किया जाता हैbazel syncजब--configureपैरामीटर को पास किया जाता है (अगर विशेषता सेट नहीं है, तो इस आदेश से फिर से फ़ेच नहीं होगा) अगर
localफ़्लैग सेट किया गया है, तो ऊपर दिए गए मामलों के अलावा, डेटा स्टोर करने की जगह बेज़ल सर्वर के रीस्टार्ट होने या असर डालने वाली किसी फ़ाइल पर भी फिर से लाया जाता है रिपॉज़िटरी की जानकारी में बदलाव होता है (जैसे किWORKSPACEफ़ाइल या फ़ाइल यह लोड होता है) से कोई फ़र्क नहीं पड़ता कि इन बदलावों की वजह से या उसके कोड का एलान.इन मामलों में, नॉन-लोकल रिपॉज़िटरी को फिर से फ़ेच नहीं किया जाता. ऐसा इसलिए है, क्योंकि इन रिपॉज़िटरी को नेटवर्क से कनेक्ट करने या अन्य तरीकों से इस्तेमाल करने पर ज़्यादा खर्च आता है.
लागू करने की सुविधा को फिर से शुरू करना
अगर किसी डिपेंडेंसी का अनुरोध किया जाता है और वह मौजूद नहीं है, तो रिपॉज़िटरी को फ़ेच करते समय, लागू करने वाले फ़ंक्शन को फिर से शुरू किया जा सकता है. ऐसे में, लागू करने वाले फ़ंक्शन का इस्तेमाल बंद हो जाएगा. साथ ही, फ़ंक्शन को फिर से लागू करने के लिए, डिपेंडेंसी को ठीक किया जाएगा. ज़रूरत से ज़्यादा रीस्टार्ट (जो कि महंगे होते हैं, क्योंकि नेटवर्क ऐक्सेस को दोबारा करना पड़ सकता है) से बचने के लिए, लेबल के आर्ग्युमेंट पहले से फ़ेच किए जाते हैं. हालांकि, ऐसा तब ही किया जाता है, जब सभी लेबल के आर्ग्युमेंट को किसी मौजूदा फ़ाइल में हल किया जा सकता हो. ध्यान दें कि सिर्फ़ फ़ंक्शन के दौरान बनाई गई स्ट्रिंग या लेबल से पाथ को हल करने पर भी, रीस्टार्ट हो सकता है.
बाहरी रिपॉज़िटरी को फिर से फ़ेच करने के लिए मजबूर करना
कभी-कभी, किसी बाहरी रिपॉज़िटरी की परिभाषा या डिपेंडेंसी में कोई बदलाव किए बिना भी वह पुरानी हो सकती है. उदाहरण के लिए, सोर्स फ़ेच करने वाली कोई रिपॉज़िटरी, तीसरे पक्ष की किसी रिपॉज़िटरी की किसी खास शाखा का पालन कर सकती है और उस शाखा पर नए कमिट उपलब्ध होते हैं. इस मामले में, bazel sync को कॉल करके, bazel से सभी बाहरी रिपॉज़िटरी को बिना किसी शर्त के फिर से फ़ेच करने के लिए कहा जा सकता है.
इसके अलावा, कुछ नियम स्थानीय मशीन की जांच करते हैं. अगर स्थानीय मशीन को अपग्रेड किया जाता है, तो हो सकता है कि ये नियम पुराने हो जाएं. यहां पर आप बेज़ल को यह काम करने के लिए कह सकते हैं
सिर्फ़ उन बाहरी डेटा स्टोर करने की जगहों को फिर से लाएं जहां
repository_rule
परिभाषा में configure एट्रिब्यूट सेट है, इसके लिए bazel sync --configure इस्तेमाल करें.
उदाहरण
C++ अपने-आप कॉन्फ़िगर होने वाला टूलचेन: यह रिपॉज़िटरी नियम का इस्तेमाल करता है, ताकि स्थानीय C++ कंपाइलर की खोज करके, बेज़ल के लिए C++ कॉन्फ़िगरेशन फ़ाइलें देखने के लिए, और फ़्लैग, C++ कंपाइलर के साथ काम करते हैं.
डेटा स्टोर करने की जगह पर जाएं डिपेंडेंसी की सूची तय करने के लिए कई
repository_ruleका इस्तेमाल करता है Go के नियमों का इस्तेमाल करना ज़रूरी होता है.rules_jvm_external, डिफ़ॉल्ट रूप से
@mavenनाम की एक बाहरी रिपॉज़िटरी बनाता है. यह ट्रांज़िटिव डिपेंडेंसी ट्री में मौजूद हर Maven आर्टफ़ैक्ट के लिए, बिल्ड टारगेट जनरेट करता है.