इस पेज पर, डेटा स्टोर करने के नियम बनाने का तरीका बताया गया है. साथ ही, ज़्यादा जानकारी के लिए उदाहरण दिए गए हैं.
बाहरी डेटा स्टोर करने की जगह एक ऐसा नियम है जिसका इस्तेमाल सिर्फ़
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एट्रिब्यूट से बताया गया हो. उन एनवायरमेंट वैरिएबल की वैल्यू को कमांड लाइन से लागू किया जा सकता है. इसके लिए,--action_envफ़्लैग का इस्तेमाल किया जाता है. हालांकि, इस फ़्लैग से बिल्ड की हर कार्रवाई अमान्य हो जाएगी. - लेबल के इस्तेमाल और इस्तेमाल की गई किसी भी फ़ाइल का कॉन्टेंट (उदाहरण के लिए,
//mypkg:label.txtन किmypkg/label.txt).
डेटा स्टोर करने की बाहरी जगहों को ज़बरदस्ती फ़ेच करें
कभी-कभी, कोई बाहरी रिपॉज़िटरी अपनी परिभाषा या डिपेंडेंसी में कोई बदलाव किए बिना पुराना हो सकता है. उदाहरण के लिए, रिपॉज़िटरी के स्रोत किसी तीसरे पक्ष के रिपॉज़िटरी (डेटा स्टोर करने की जगह) की किसी खास ब्रांच को फ़ॉलो कर सकते हैं. साथ ही, उस ब्रांच पर नए कम्यूनिकेशन उपलब्ध होते हैं. इस मामले में, आप बेजल को bazel sync पर कॉल करके, सभी
डेटा स्टोर करने की जगहों को बिना किसी शर्त के फ़ेच करने के लिए कह सकते हैं.
इसके अलावा, कुछ नियम स्थानीय मशीन की जांच करते हैं और
स्थानीय मशीन को अपग्रेड करने पर पुराने हो सकते हैं. यहां, आप बेज़ल से उन बाहरी डेटा स्टोर करने की जगहों को फिर से फ़ेच करने के लिए कह सकते हैं जहां repository_rule परिभाषा में configure एट्रिब्यूट सेट किया गया है. इसके लिए, bazel sync --configure का इस्तेमाल करें.
उदाहरण
C++ अपने-आप कॉन्फ़िगर होने वाले टूलचेन: यह डेटा इकट्ठा करने के नियम का इस्तेमाल करता है, ताकि स्थानीय C++ कंपाइलर, C++ कंपाइलर के साथ काम करने वाले और फ़्लैग करने वाले C++ कंपाइलर को खोज कर, C++ की कॉन्फ़िगरेशन फ़ाइलें अपने-आप बन जाएं.
Go repositories Go नियमों का इस्तेमाल करने के लिए ज़रूरी डिपेंडेंसी की सूची तय करने के लिए कई
repository_ruleइस्तेमाल करता है.rule_jvm_external डिफ़ॉल्ट रूप से
@mavenनाम का एक बाहरी रिपॉज़िटरी बनाता है. यह ट्रांज़िटिव डिपेंडेंसी ट्री में हर मेवन आर्टफ़ैक्ट के लिए बिल्ड टारगेट जनरेट करता है.