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

इस पेज पर, डेटा स्टोर करने के नियम बनाने का तरीका बताया गया है. साथ ही, देखें.

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

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

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

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

नियम तब लोड होता है, जब आप इसे साफ़ तौर पर बनाते हैं या अगर यह बिल्ड. इस मामले में, Basel अपने implementation फ़ंक्शन को एक्ज़ीक्यूट करेगा. यह फ़ंक्शन के बारे में बताती है कि रिपॉज़िटरी, उसका कॉन्टेंट, और BUILD फ़ाइलें कैसे बनाई जाती हैं.

विशेषताएं

एट्रिब्यूट, नियम के ऐसे तर्क होते हैं जिन्हें attrs नियम के तर्क के लिए, लिखवाने के तौर पर पास किया जाता है. विशेषताएं और उनके प्रकार तब बताए जाते हैं, जब आप डेटा स्टोर करने की जगह का नियम है. url और sha256 एट्रिब्यूट की जानकारी देने वाला उदाहरण स्ट्रिंग:

local_repository = repository_rule(
    implementation=_impl,
    local=True,
    attrs={
        "url": attr.string(mandatory=True)
        "sha256": attr.string(mandatory=True)
    }
)

लागू करने के फ़ंक्शन में किसी एट्रिब्यूट को ऐक्सेस करने के लिए, repository_ctx.attr.<attribute_name>:

def _impl(repository_ctx):
    url = repository_ctx.attr.url
    checksum = repository_ctx.attr.sha256

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

लागू करने का फ़ंक्शन कब चलाया जाता है?

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

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

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

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

• अगर configure फ़्लैग सेट किया गया है, तो डेटा स्टोर करने की जगह को सिर्फ़ फिर से फ़ेच किया जाता है bazel sync जब --configure पैरामीटर को पास किया जाता है (अगर विशेषता सेट नहीं है, तो इस आदेश से फिर से फ़ेच नहीं होगा)

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

  ऐसे मामलों में, डेटा स्टोर करने की गैर-स्थानीय जगहों को फिर से नहीं लाया जाता. ऐसा इसलिए है, क्योंकि यह माना जाएगा कि डेटा स्टोर करने की ये जगहें, नेटवर्क से जुड़ी हुई हैं या किसी और तरह से हैं महंगा.

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

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

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

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

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

उदाहरण

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

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

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