बेज़ल रजिस्ट्री

Bazel, डिपेंडेंसी की जानकारी पाने के लिए, Bazel रजिस्ट्रियों से अनुरोध करता है. ये Bazel मॉड्यूल के डेटाबेस होते हैं. Bazel सिर्फ़ एक तरह की रजिस्ट्रियों — इंडेक्स रजिस्ट्रियों — को सपोर्ट करता है. ये स्थानीय डायरेक्ट्री या स्टैटिक एचटीटीपी सर्वर होते हैं, जो किसी खास फ़ॉर्मैट में काम करते हैं.

इंडेक्स रजिस्ट्री

इंडेक्स रजिस्ट्री, स्थानीय डायरेक्ट्री या स्टैटिक एचटीटीपी सर्वर होती है. इसमें मॉड्यूल की सूची के बारे में जानकारी होती है. जैसे, उनका होम पेज, उन्हें मैनेज करने वाले लोग, हर वर्शन की MODULE.bazel फ़ाइल, और हर वर्शन का सोर्स पाने का तरीका. खास तौर पर, इसे सोर्स के संग्रह को खुद से दिखाने की ज़रूरत नहीं होती.

इंडेक्स रजिस्ट्री का फ़ॉर्मैट यह होना चाहिए:

• /bazel_registry.json: यह एक वैकल्पिक JSON फ़ाइल है. इसमें रजिस्ट्री के लिए मेटाडेटा होता है.
• /modules: यह एक डायरेक्ट्री है. इसमें इस रजिस्ट्री में मौजूद हर मॉड्यूल के लिए एक सब-डायरेक्ट्री होती है
• /modules/$MODULE: यह एक डायरेक्ट्री है. इसमें $MODULE नाम के मॉड्यूल के हर वर्शन के लिए एक सब-डायरेक्ट्री होती है. साथ ही, इसमें metadata.json फ़ाइल भी होती है. इसमें इस मॉड्यूल के लिए मेटाडेटा होता है.
• /modules/$MODULE/$VERSION: यह एक डायरेक्ट्री है. इसमें ये फ़ाइलें होती हैं:
  • MODULE.bazel: यह इस मॉड्यूल वर्शन की MODULE.bazel फ़ाइल है. ध्यान दें कि यह MODULE.bazel फ़ाइल, Bazel की बाहरी डिपेंडेंसी रिज़ॉल्यूशन के दौरान पढ़ी जाती है. यह सोर्स संग्रह की फ़ाइल नहीं होती. हालांकि, अगर रजिस्ट्री से अलग कोई सेटिंग नहीं की गई है, तो यह सोर्स संग्रह की फ़ाइल हो सकती है (जब तक कोई नॉन-रजिस्ट्री ओवरराइड न हो). यह भी ध्यान दें कि रिलीज़ का वर्शन सेट करने के लिए, इस फ़ाइल का इस्तेमाल करना सबसे अच्छा होता है. सोर्स संग्रह की MODULE.bazel फ़ाइल में ऐसा न करें. मॉड्यूल वर्शन के बारे में ज़्यादा जानने के लिए, अक्सर पूछे जाने वाले सवाल देखें.
  • source.json: यह एक JSON फ़ाइल है. इसमें इस मॉड्यूल वर्शन का सोर्स पाने के तरीके के बारे में जानकारी होती है
  • patches/: यह एक वैकल्पिक डायरेक्ट्री है. इसमें पैच फ़ाइलें होती हैं. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json में "संग्रह" टाइप हो
  • overlay/: यह एक वैकल्पिक डायरेक्ट्री है. इसमें ओवरले फ़ाइलें होती हैं. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json में "संग्रह" टाइप हो

bazel_registry.json

bazel_registry.json एक वैकल्पिक फ़ाइल है. इसमें पूरे रजिस्ट्री पर लागू होने वाला मेटाडेटा होता है. इसमें ये फ़ील्ड हो सकते हैं:

• mirrors: यह स्ट्रिंग की एक कैटगरी है. इसमें सोर्स संग्रह के लिए इस्तेमाल किए जाने वाले मिरर की सूची होती है.
  • मिरर किया गया यूआरएल, मिरर और मॉड्यूल के सोर्स यूआरएल को जोड़कर बनता है. यह सोर्स यूआरएल, प्रोटोकॉल के बिना, उसकी source.json फ़ाइल में दिया गया होता है. उदाहरण के लिए, अगर किसी मॉड्यूल का सोर्स यूआरएल https://foo.com/bar/baz है और mirrors में ["https://mirror1.com/", "https://example.com/mirror2/"] शामिल है, तो Bazel इन यूआरएल को इस क्रम में आज़माएगा: https://mirror1.com/foo.com/bar/baz, https://example.com/mirror2/foo.com/bar/baz. इसके बाद, ओरिजनल सोर्स यूआरएल https://foo.com/bar/baz को आज़माएगा.
• module_base_path: यह एक स्ट्रिंग है. इसमें source.json फ़ाइल में local_path टाइप वाले मॉड्यूल के लिए, बेस पाथ की जानकारी होती है

metadata.json

metadata.json एक वैकल्पिक JSON फ़ाइल है. इसमें मॉड्यूल के बारे में जानकारी होती है. इसमें ये फ़ील्ड शामिल होते हैं:

• versions: यह स्ट्रिंग की एक कैटगरी है. इसमें हर स्ट्रिंग, इस रजिस्ट्री में उपलब्ध मॉड्यूल के एक वर्शन को दिखाती है. यह कैटगरी, मॉड्यूल डायरेक्ट्री के चाइल्ड से मेल खानी चाहिए.
• yanked_versions: यह एक JSON ऑब्जेक्ट है. इसमें इस मॉड्यूल के yanked versions वर्शन की जानकारी होती है. कुंजियां, yank करने के लिए वर्शन होनी चाहिए. वहीं, वैल्यू में यह जानकारी होनी चाहिए कि वर्शन को yank क्यों किया गया है. इसमें ज़्यादा जानकारी का लिंक भी होना चाहिए.

ध्यान दें कि बीसीआर के लिए, metadata.json फ़ाइल में ज़्यादा जानकारी की ज़रूरत होती है.

source.json

source.json एक ज़रूरी JSON फ़ाइल है. इसमें मॉड्यूल के किसी खास वर्शन को पाने के तरीके के बारे में जानकारी होती है. इस फ़ाइल का स्कीमा, इसके type फ़ील्ड पर निर्भर करता है. इसकी डिफ़ॉल्ट वैल्यू archive होती है.

• अगर type की वैल्यू archive (डिफ़ॉल्ट) है, तो इस मॉड्यूल वर्शन को http_archive रिपॉज़िट्री नियम से बैक अप किया जाता है. इसे किसी दिए गए यूआरएल से संग्रह डाउनलोड करके और उसका कॉन्टेंट निकालकर पाया जाता है. यह इन फ़ील्ड को सपोर्ट करता है:
  • url: यह एक स्ट्रिंग है. इसमें सोर्स संग्रह का यूआरएल होता है
  • mirror_urls: यह स्ट्रिंग की एक सूची है. इसमें सोर्स संग्रह के मिरर यूआरएल होते हैं. बैकअप के तौर पर, url के बाद यूआरएल को इस क्रम में आज़माया जाता है.
  • integrity: यह एक स्ट्रिंग है. इसमें संग्रह का सबरिसॉर्स इंटिग्रिटी चेकसम होता है
  • strip_prefix: यह एक स्ट्रिंग है. इसमें सोर्स संग्रह को निकालते समय, डायरेक्ट्री का प्रीफ़िक्स होता है जिसे हटाना होता है
  • overlay: यह एक JSON ऑब्जेक्ट है. इसमें निकाले गए संग्रह के ऊपर लेयर करने के लिए, ओवरले फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/overlay डायरेक्ट्री में मौजूद होती हैं. कुंजियां, ओवरले फ़ाइल के नाम होती हैं. वहीं, वैल्यू में ओवरले फ़ाइलों का इंटिग्रिटी चेकसम होता है. ओवरले, पैच फ़ाइलों से पहले लागू किए जाते हैं.
  • patches: यह एक JSON ऑब्जेक्ट है. इसमें निकाले गए संग्रह पर लागू करने के लिए, पैच फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/patches डायरेक्ट्री में मौजूद होती हैं. कुंजियां, पैच फ़ाइल के नाम होती हैं. वहीं, वैल्यू में पैच फ़ाइलों का इंटिग्रिटी चेकसम होता है. पैच, ओवरले फ़ाइलों के बाद और patches में दिखने वाले क्रम में लागू किए जाते हैं.
  • patch_strip: यह एक संख्या है. यह Unix patch के --strip आर्ग्युमेंट के बराबर होती है.
  • archive_type: यह एक स्ट्रिंग है. इसमें डाउनलोड की गई फ़ाइल का संग्रह टाइप होता है. यह type पर मौजूद http_archive के बराबर होता है.
• अगर type की वैल्यू git_repository है, तो इस मॉड्यूल वर्शन को a git_repository रिपॉज़िट्री नियम से बैक अप किया जाता है. इसे Git रिपॉज़िट्री को क्लोन करके पाया जाता है.
  • इन फ़ील्ड का इस्तेमाल किया जा सकता है. इन्हें सीधे तौर पर, git_repository रिपॉज़िट्री नियम में फ़ॉरवर्ड किया जाता है: remote, commit, shallow_since, tag, init_submodules, verbose, और strip_prefix, patch_strip.
  • patches: यह एक JSON ऑब्जेक्ट है. इसमें क्लोन की गई रिपॉज़िट्री पर लागू करने के लिए, पैच फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/patches डायरेक्ट्री में मौजूद होती हैं. कुंजियां, पैच फ़ाइल के नाम होती हैं. वहीं, वैल्यू में पैच फ़ाइलों का इंटिग्रिटी चेकसम होता है. पैच, patches में दिखने वाले क्रम में लागू किए जाते हैं.
• अगर type की वैल्यू local_path है, तो इस मॉड्यूल वर्शन को local_repository रिपॉज़िट्री नियम से बैक अप किया जाता है. इसे लोकल डिस्क पर मौजूद किसी डायरेक्ट्री से सिमलंक किया जाता है. यह इस फ़ील्ड को सपोर्ट करता है:
  • path: यह रिपॉज़िट्री का लोकल पाथ है. इसकी गिनती इस तरह की जाती है:
    • अगर path एक ऐब्सलूट पाथ है, तो यह वैसा ही रहता है
    • अगर path एक रिलेटिव पाथ है और module_base_path एक ऐब्सलूट पाथ है, तो यह <module_base_path>/<path> पर रिज़ॉल्व होता है
    • अगर path और module_base_path, दोनों रिलेटिव पाथ हैं, तो यह <registry_path>/<module_base_path>/<path> पर रिज़ॉल्व होता है. रजिस्ट्री को स्थानीय तौर पर होस्ट किया जाना चाहिए और --registry=file://<registry_path> का इस्तेमाल करके ऐक्सेस किया जाना चाहिए. ऐसा न करने पर, Bazel एक गड़बड़ी दिखाएगा

Bazel Central Registry

Bazel Central Registry (बीसीआर), https://bcr.bazel.build/ पर मौजूद एक इंडेक्स रजिस्ट्री है. इसका कॉन्टेंट, GitHub रिपॉज़िट्री bazelbuild/bazel-central-registry से बैक अप होता है. इसके कॉन्टेंट को, https://registry.bazel.build/ पर मौजूद वेब फ़्रंटएंड का इस्तेमाल करके ब्राउज़ किया जा सकता है.

बीसीआर को Bazel कम्यूनिटी मैनेज करती है. इसमें योगदान देने वाले लोग, पुल अनुरोध सबमिट कर सकते हैं. बीसीआर में योगदान देने के लिए दिशा-निर्देश देखें.

बीसीआर के लिए, सामान्य इंडेक्स रजिस्ट्री के फ़ॉर्मैट के अलावा, हर मॉड्यूल वर्शन के लिए presubmit.yml फ़ाइल की ज़रूरत होती है (/modules/$MODULE/$VERSION/presubmit.yml). इस फ़ाइल में, कुछ ज़रूरी बिल्ड और टेस्ट टारगेट की जानकारी होती है. इनका इस्तेमाल, इस मॉड्यूल वर्शन की पुष्टि करने के लिए किया जा सकता है. बीसीआर की सीआई पाइपलाइन भी इसका इस्तेमाल, मॉड्यूल के बीच इंटरऑपरेबिलिटी पक्का करने के लिए करती है.

रजिस्ट्रियां चुनना

Bazel के दोहराए जा सकने वाले फ़्लैग --registry का इस्तेमाल, उन रजिस्ट्रियों की सूची तय करने के लिए किया जा सकता है जिनसे मॉड्यूल का अनुरोध करना है. इससे, अपने प्रोजेक्ट को तीसरे पक्ष या इंटरनल रजिस्ट्री से डिपेंडेंसी फ़ेच करने के लिए सेट अप किया जा सकता है. पहले की रजिस्ट्रियों को प्राथमिकता दी जाती है. सुविधा के लिए, अपने प्रोजेक्ट की .bazelrc फ़ाइल में --registry फ़्लैग की सूची जोड़ी जा सकती है.

अगर आपकी रजिस्ट्री GitHub पर होस्ट की गई है (उदाहरण के लिए, bazelbuild/bazel-central-registry के फ़ोर्क के तौर पर), तो --registry की वैल्यू के लिए, raw.githubusercontent.com में GitHub का रॉ पता होना चाहिए. उदाहरण के लिए, main ब्रांच पर my-org फ़ोर्क, आपको सेट करना होगा --registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/.

--registry फ़्लैग का इस्तेमाल करने पर, Bazel Central Registry का इस्तेमाल डिफ़ॉल्ट रूप से नहीं किया जा सकेगा. हालांकि, --registry=https://bcr.bazel.build जोड़कर, इसे वापस जोड़ा जा सकता है.