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

नाइटली रिलीज़ · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

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

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

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

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

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 ऑब्जेक्ट है. इसमें इस मॉड्यूल के हटाए गए वर्शन के बारे में जानकारी होती है. कुंजियां, यैंक किए जाने वाले वर्शन होने चाहिए. साथ ही, वैल्यू में यह जानकारी होनी चाहिए कि वर्शन को क्यों यैंक किया गया है. इसमें ज़्यादा जानकारी के लिए लिंक भी शामिल होना चाहिए.

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

source.json

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

  • अगर type archive (डिफ़ॉल्ट) है, तो इस मॉड्यूल वर्शन को http_archive repo rule से बैक अप लिया जाता है. इसे दिए गए यूआरएल से संग्रह डाउनलोड करके और उसके कॉन्टेंट को निकालकर फ़ेच किया जाता है. यह इन फ़ील्ड के साथ काम करता है:
    • url: यह एक स्ट्रिंग है. यह सोर्स संग्रह का यूआरएल होता है
    • mirror_urls: यह स्ट्रिंग की एक सूची होती है. इसमें सोर्स संग्रह के मिरर यूआरएल होते हैं. url के बाद, यूआरएल को बैकअप के तौर पर क्रम से इस्तेमाल किया जाता है.
    • integrity: एक स्ट्रिंग, संग्रह का Subresource Integrity चेकसम
    • strip_prefix: एक स्ट्रिंग, सोर्स संग्रह निकालते समय डायरेक्ट्री के प्रीफ़िक्स को हटाने के लिए
    • overlay: यह एक JSON ऑब्जेक्ट है. इसमें एक्सट्रैक्ट किए गए संग्रह के ऊपर लेयर करने के लिए ओवरले फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/overlay डायरेक्ट्री में मौजूद होती हैं. कुंजियां, ओवरले फ़ाइल के नाम होती हैं और वैल्यू, ओवरले फ़ाइलों के इंटिग्रिटी चेकसम होते हैं. पैच फ़ाइलों से पहले ओवरले लागू किए जाते हैं.
    • patches: यह एक JSON ऑब्जेक्ट है. इसमें एक्सट्रैक्ट किए गए संग्रह पर लागू करने के लिए पैच फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/patches डायरेक्ट्री में मौजूद होती हैं. कुंजियां, पैच फ़ाइल के नाम होती हैं और वैल्यू, पैच फ़ाइलों के इंटिग्रिटी चेकसम होते हैं. पैच, ओवरले फ़ाइलों के बाद लागू किए जाते हैं. साथ ही, वे patches में दिखने वाले क्रम में लागू होते हैं.
    • patch_strip: एक संख्या; यह Unix patch फ़ंक्शन के --strip आर्ग्युमेंट के बराबर होती है.
    • archive_type: यह एक स्ट्रिंग है. यह डाउनलोड की गई फ़ाइल के संग्रह का टाइप है (यह type on http_archive के जैसा ही है).
  • अगर type git_repository है, तो इस मॉड्यूल के वर्शन को git_repository repo rule से बैक अप लिया जाता है. इसे Git रिपॉज़िटरी को क्लोन करके फ़ेच किया जाता है.
    • इन फ़ील्ड का इस्तेमाल किया जा सकता है. इनकी वैल्यू, सीधे तौर पर git_repository repo के नियम को भेजी जाती है: remote, commit, shallow_since, tag, init_submodules, verbose, और strip_prefix.
  • अगर 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 (BCR), https://bcr.bazel.build/ पर मौजूद है. यह एक इंडेक्स रजिस्ट्री है. इसमें मौजूद कॉन्टेंट, GitHub रिपो bazelbuild/bazel-central-registry से लिया गया है. इसके कॉन्टेंट को https://registry.bazel.build/ पर जाकर, वेब फ़्रंटएंड का इस्तेमाल करके ब्राउज़ किया जा सकता है.

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

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

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

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

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

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