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

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

एक बाहरी डेटाबेस एक ऐसा नियम है जिसका इस्तेमाल सिर्फ़ 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 एट्रिब्यूट के repository_rule साथ तय किए गए किसी भी एनवायरमेंट वैरिएबल की वैल्यू. कमांड लाइन से --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 आर्टफ़ैक्ट के लिए, बिल्ड टारगेट जनरेट करता है.