तारीख सेव करें: BazelCon 2023, 24 से 25 अक्टूबर तक Google म्यूनिख में होगा! ज़्यादा जानें

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

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

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

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

रिपॉज़िटरी नियम बनाना

किसी .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,
    ...)

लागू करने का फ़ंक्शन कब शुरू होता है?

डेटा स्टोर करने की जगह को लागू करने का फ़ंक्शन तब निष्पादित किया जाता है, जब Bazel को डेटा स्टोर करने की उस जगह से किसी टारगेट की ज़रूरत होती है, उदाहरण के लिए, जब कोई दूसरा टारगेट (किसी दूसरे डेटा संग्रह की जगह में) इस पर निर्भर होता है या जब कमांड फ़ील्ड में उसका ज़िक्र होता है. इसके बाद, लागू करने की सुविधा का फ़ाइल सिस्टम में रिपॉज़िटरी बनाने की उम्मीद की जाती है. इसे रिपॉज़िटरी "फ़ेचिंग" कहा जाता है.

सामान्य टारगेट के उलट, डेटा स्टोर करने की जगह में बदलाव होने पर, डेटा स्टोर करने की जगह को फिर से फ़ेच करना ज़रूरी नहीं होता. ऐसा कुछ वजहों से बेज़ेल या तो बदलावों की पहचान नहीं कर पाता या हर बिल्ड पर बहुत ज़्यादा ओवरहेड बना देता है (उदाहरण के लिए, ऐसी चीज़ें जो नेटवर्क से फ़ेच की जाती हैं). इसलिए, डेटा स्टोर करने की जगह को फिर से सिर्फ़ तब फ़ेच किया जाता है, जब इनमें से कोई एक चीज़ बदलती है:

  • WORKSPACE फ़ाइल में, डेटा स्टोर करने की जगह के एलान में पास किए गए पैरामीटर.
  • Starlark कोड में रिपॉज़िटरी को लागू करना शामिल है.
  • repository_rule के environ एट्रिब्यूट के साथ बताए गए किसी भी एनवायरमेंट वैरिएबल की वैल्यू. इन एनवायरमेंट वैरिएबल की वैल्यू, कमांड लाइन पर --action_env फ़्लैग (हालांकि, फ़्लैग की वजह से बिल्ड की हर कार्रवाई अमान्य हो जाएगी) पर हार्ड वायर हो सकती है.
  • किसी भी फ़ाइल का कॉन्टेंट, read(), execute(), और repository_ctx के ऐसे ही तरीकों से भेजा जाता है जिन्हें लेबल की मदद से बताया जाता है. जैसे, //mypkg:label.txt, लेकिन mypkg/label.txt से नहीं.
  • bazel sync कब चलाया जाएगा.

repository_rule के दो पैरामीटर होते हैं जो डेटा स्टोर करने की जगह को फिर से फ़ेच किए जाने पर कंट्रोल करते हैं:

  • अगर configure फ़्लैग सेट किया जाता है, तो --configure पैरामीटर को पास करने पर, डेटा स्टोर करने की जगह को सिर्फ़ bazel sync पर फिर से फ़ेच किया जाता है (अगर एट्रिब्यूट को सेट नहीं किया जाता, तो इस कमांड से फिर से फ़ेच नहीं होगा)
  • अगर ऊपर बताए गए मामलों के अलावा, local फ़्लैग सेट किया जाता है, तो डेटा स्टोर करने की जगह को बैज के सर्वर को रीस्टार्ट करने पर या डेटा स्टोर करने की जगह के एलान पर असर डालने वाली किसी फ़ाइल (जैसे, WORKSPACE फ़ाइल या फ़ाइल लोड होने पर) को भी फिर से फ़ेच किया जाता है. इससे कोई फ़र्क़ नहीं पड़ता कि डेटा स्टोर करने की जगह या उसके कोड में एलान किया गया है या नहीं.

    इन मामलों में, डेटा स्टोर करने की गैर-स्थानीय जगहों को फिर से फ़ेच नहीं किया जाता. इसकी वजह यह है कि इन रिपॉज़िटरी को नेटवर्क से बात करने वाला माना जाता है या ये महंगे होते हैं.

लागू करने वाला फ़ंक्शन रीस्टार्ट हो रहा है

जब डेटा किसी डिपेंडेंसी के लिए अनुरोध करता है, तो फ़ंक्शन को फिर से शुरू किया जा सकता है. इस तरह के मामलों में, लागू करने का फ़ंक्शन बंद हो जाएगा, डिपेंडेंसी का समाधान हो जाएगा, और डिपेंडेंसी का समाधान हो जाने के बाद फ़ंक्शन फिर से लागू हो जाएगा. ग़ैर-ज़रूरी रीस्टार्ट से बचने के लिए (जो महंगे होते हैं, क्योंकि नेटवर्क का ऐक्सेस दोहराना पड़ सकता है), लेबल के आर्ग्युमेंट को प्रीफ़ेच किया जाता है. हालांकि, यह ज़रूरी है कि लेबल के सभी आर्ग्युमेंट किसी मौजूदा फ़ाइल पर ठीक किए जा सकें. ध्यान दें कि किसी ऐसे स्ट्रिंग या लेबल से बने पाथ को हल करने से अब भी रीस्टार्ट हो सकता है जो सिर्फ़ फ़ंक्शन के चलने के दौरान बनाया गया था.

बाहरी डेटा स्टोर करने की जगहों को फिर से फ़ेच करने के लिए

कभी-कभी, डेटा स्टोर करने की बाहरी जगह की परिभाषा या डिपेंडेंसी में बिना कोई बदलाव किए, वह पुराना हो सकता है. उदाहरण के लिए, डेटा स्टोर करने की जगह पर डेटा फ़ेच करने वाले सोर्स, तीसरे पक्ष के डेटा स्टोर करने की किसी खास जगह की किसी खास ब्रांच को फ़ॉलो कर सकते हैं. साथ ही, उस ब्रांच पर नई प्रतिबद्धताएं भी उपलब्ध हो जाती हैं. इस मामले में, आप बेज़ल से bazel sync पर कॉल करके, सभी बाहरी रिपॉज़िटरी को फिर से फ़ेच करने के लिए कह सकते हैं.

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

उदाहरण

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

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

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