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

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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 का टाइप "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 रेपो के नियम के तहत बैक अप लिया जाता है. इसे 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 (BCR), https://bcr.bazel.build/ पर मौजूद एक इंडेक्स रजिस्ट्री है. इसमें मौजूद कॉन्टेंट, GitHub repo 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 जोड़कर इसे फिर से चालू किया जा सकता है.