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

समस्या की शिकायत करें सोर्स देखें

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

एक्सटर्नल रिपॉज़िटरी एक ऐसा नियम है जिसका इस्तेमाल सिर्फ़ WORKSPACE फ़ाइल में किया जा सकता है. साथ ही, यह बेज़ल की लोडिंग फ़ेज़ पर नॉन-हर्मेटिक ऑपरेशन की सुविधा देता है. डेटा स्टोर करने की जगह का हर नियम, अपनी BUILD फ़ाइलों और आर्टफ़ैक्ट के साथ अपना फ़ाइल फ़ोल्डर बनाता है. इनका इस्तेमाल तीसरे पक्ष की लाइब्रेरी (जैसे कि Maven के पैकेज की गई लाइब्रेरी) पर निर्भर रहने के लिए किया जा सकता है. साथ ही, इनका इस्तेमाल होस्ट Basel के चल रहे होस्ट के लिए खास BUILD फ़ाइलों को जनरेट करने के लिए भी किया जा सकता है.

डेटा स्टोर करने के लिए नियम बनाना

.bzl फ़ाइल में, डेटा स्टोर करने का नया नियम बनाने और उसे ग्लोबल वैरिएबल में सेव करने के लिए, repository_rule फ़ंक्शन का इस्तेमाल करें.

कस्टम रिपॉज़िटरी के नियम का इस्तेमाल, नेटिव रिपॉज़िटरी के नियम की तरह ही किया जा सकता है. इसमें एक ज़रूरी name एट्रिब्यूट है और इसकी बिल्ड फ़ाइलों में मौजूद हर टारगेट को @<name>//package:target कहा जा सकता है, जहां <name>, name एट्रिब्यूट की वैल्यू है.

नियम तब लोड होता है, जब आपने साफ़ तौर पर इसे बनाया हो या यह बिल्ड पर डिपेंडेंसी हो. इस मामले में, Basel अपने 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 दिखाता है, ताकि यह बताया जा सके कि तय किए गए पैरामीटर के आधार पर नियम को फिर से बनाया जा सकता है या उस नियम के लिए पैरामीटर के सेट के साथ एक ऐसा लिखवाने की सुविधा मिलती है जो उस नियम को उसी रिपॉज़िटरी को जनरेट करने वाले फिर से जनरेट किए जा सकने वाले नियम में बदल देता है. उदाहरण के लिए, किसी नियम के लिए जो GitHub रिपॉज़िटरी को ट्रैक करता है, जिसका मतलब मूल रूप से तय की गई फ़्लोटिंग ब्रांच के बजाय कोई खास कमिट आइडेंटिफ़ायर देना होगा.

इनपुट पैरामीटर 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 पर कॉल करना होगा.

इसके अलावा, कुछ नियम लोकल मशीन की जांच करते हैं और अगर लोकल मशीन को अपग्रेड किया गया था, तो हो सकता है कि नियम पुराने हो जाएं. यहां, Baज़ल को सिर्फ़ उन बाहरी डेटा स्टोर करने की जगहों को फिर से फ़ेच करने के लिए कहा जा सकता है जहां repository_rule परिभाषा में configure एट्रिब्यूट सेट है. इसके लिए, bazel sync --configure का इस्तेमाल करें.

उदाहरण

  • C++ अपने-आप कॉन्फ़िगर होने वाला टूलचेन: यह रिपॉज़िटरी के नियम का इस्तेमाल करता है. इससे बज़ल के लिए अपने-आप C++ कॉन्फ़िगरेशन फ़ाइलें बन जाती हैं. इसके लिए, वह लोकल C++ कंपाइलर, एनवायरमेंट, और C++ कंपाइलर के साथ काम करने वाले फ़्लैग की खोज करता है.

  • Go रिपॉज़िटरी में, Go नियमों का इस्तेमाल करने के लिए ज़रूरी डिपेंडेंसी की सूची तय करने के लिए, कई repository_rule का इस्तेमाल किया जाता है.

  • rules_jvm_external डिफ़ॉल्ट रूप से, @maven नाम का एक बाहरी डेटा स्टोर करता है. यह ट्रांज़िटिव डिपेंडेंसी ट्री में हर Maven आर्टफ़ैक्ट के लिए, बिल्ड टारगेट जनरेट करता है.