रिपॉज़िटरी के नियम

इस पेज पर, डेटा स्टोर करने के नियम बनाने का तरीका बताया गया है. साथ ही, ज़्यादा जानकारी के लिए उदाहरण भी दिए गए हैं.

बाहरी रिपॉज़िटरी एक ऐसा नियम है जिसका इस्तेमाल सिर्फ़ WORKSPACE फ़ाइल में किया जा सकता है. साथ ही, यह Bazel के लोडिंग फ़ेज़ में नॉन-हर्मेटिक ऑपरेशन को चालू करता है. हर बाहरी रिपॉज़िटरी नियम, अपनी BUILD फ़ाइलों और आर्टफ़ैक्ट के साथ अपना वर्कस्पेस बनाता है. इनका इस्तेमाल, तीसरे पक्ष की लाइब्रेरी (जैसे, मेवन पैकेज वाली लाइब्रेरी) पर निर्भर करने के लिए किया जा सकता है. साथ ही, इनका इस्तेमाल उस होस्ट के लिए खास 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 दिखाता है. इसके अलावा, यह उस नियम के लिए पैरामीटर के सेट के साथ एक डायक्शन दिखाता है, जो उस नियम को फिर से लागू किया जा सकने वाला नियम बना देगा और वही रिपॉज़िटरी जनरेट करेगा. उदाहरण के लिए, किसी git रिपॉज़िटरी को ट्रैक करने वाले नियम के लिए, इसका मतलब है कि मूल रूप से तय की गई फ़्लोटिंग शाखा के बजाय, किसी खास कमिट आइडेंटिफ़ायर को दिखाना.

इनपुट पैरामीटर 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 आर्टफ़ैक्ट के लिए, बिल्ड टारगेट जनरेट करता है.