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

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

एक बाहरी डेटाबेस एक ऐसा नियम है जिसका इस्तेमाल सिर्फ़ 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 दिखाता है. इसका मतलब है कि तय किए गए पैरामीटर के हिसाब से नियम को फिर से बनाया जा सकता है. इसके अलावा, यह उस नियम के लिए पैरामीटर का डिक्शनरी दिखाता है. इससे नियम को फिर से बनाया जा सकता है और वही डेटाबेस जनरेट किया जा सकता है. उदाहरण के लिए, 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 एट्रिब्यूट के 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 आर्टफ़ैक्ट के लिए, बिल्ड टारगेट जनरेट करता है.