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

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

अगर आपकी रजिस्ट्री 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 जोड़कर इसे फिर से जोड़ा जा सकता है.