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