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