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

समस्या की शिकायत करें सोर्स देखें Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

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

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

इंडेक्स रजिस्ट्री को इस फ़ॉर्मैट का पालन करना होगा:

  • /bazel_registry.json: रजिस्ट्री के मेटाडेटा वाली 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_repository टाइप वाले मॉड्यूल के लिए बेस पाथ तय करना
  • /modules: एक डायरेक्ट्री, जिसमें इस रजिस्ट्री के हर मॉड्यूल के लिए एक सबडायरेक्ट्री होती है
  • /modules/$MODULE: एक डायरेक्ट्री, जिसमें इस मॉड्यूल के हर वर्शन के लिए एक सबडायरेक्ट्री होती है. साथ ही, इसमें यह भी होता है:
    • metadata.json: यह एक JSON फ़ाइल है. इसमें मॉड्यूल के बारे में जानकारी होती है. इसमें ये फ़ील्ड होते हैं:
      • homepage: प्रोजेक्ट के होम पेज का यूआरएल
      • maintainers: JSON ऑब्जेक्ट की सूची. इनमें से हर ऑब्जेक्ट, रजिस्ट्री में मॉड्यूल के रखरखाव करने वाले व्यक्ति की जानकारी से मेल खाता है. ध्यान दें कि यह ज़रूरी नहीं है कि यह प्रोजेक्ट के लेखकों के नाम से मेल खाए
      • versions: इस रजिस्ट्री में मौजूद इस मॉड्यूल के सभी वर्शन की सूची
      • yanked_versions: इस मॉड्यूल के हटाए गए वर्शन का मैप. कुंजियां, यैंक किए जाने वाले वर्शन होने चाहिए और वैल्यू में यह जानकारी होनी चाहिए कि वर्शन को क्यों यैंक किया गया है. इसमें ज़्यादा जानकारी के लिए लिंक भी शामिल होना चाहिए
  • /modules/$MODULE/$VERSION: एक डायरेक्ट्री, जिसमें ये फ़ाइलें शामिल हैं:
    • MODULE.bazel: इस मॉड्यूल वर्शन की MODULE.bazel फ़ाइल
    • source.json: यह एक JSON फ़ाइल है. इसमें इस मॉड्यूल वर्शन के सोर्स को फ़ेच करने के तरीके के बारे में जानकारी होती है
      • डिफ़ॉल्ट टाइप "archive" होता है. यह http_archive रिपॉज़िटरी को दिखाता है. इसमें ये फ़ील्ड होते हैं:
        • url: सोर्स संग्रह का यूआरएल
        • mirror_urls: यह स्ट्रिंग की एक सूची होती है. इसमें सोर्स संग्रह के मिरर यूआरएल होते हैं. बैकअप के तौर पर, url के बाद यूआरएल को क्रम से इस्तेमाल किया जाता है.
        • integrity: संग्रह का सबरीसोर्स इंटिग्रिटी चेकसम
        • strip_prefix: सोर्स संग्रह को निकालते समय हटाने के लिए डायरेक्ट्री का प्रीफ़िक्स
        • patches: यह एक ऐसा मैप होता है जिसमें निकाली गई संग्रह फ़ाइल पर लागू करने के लिए, पैच फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/patches डायरेक्ट्री में मौजूद होती हैं. कुंजियां, पैच फ़ाइल के नाम होती हैं और वैल्यू, पैच फ़ाइलों के इंटिग्रिटी चेकसम होते हैं
        • patch_strip: यह Unix patch के --strip आर्ग्युमेंट के जैसा ही है.
        • archive_type: डाउनलोड की गई फ़ाइल का संग्रह टाइप (http_archive पर मौजूद type के जैसा). डिफ़ॉल्ट रूप से, संग्रह टाइप का पता यूआरएल के फ़ाइल एक्सटेंशन से लगाया जाता है. अगर फ़ाइल का कोई एक्सटेंशन नहीं है, तो इनमें से कोई एक एक्सटेंशन साफ़ तौर पर बताया जा सकता है: "zip", "jar", "war", "aar", "tar", "tar.gz", "tgz", "tar.xz", "txz", "tar.zst", "tzst", tar.bz2, "ar" या "deb".
      • इन फ़ील्ड के साथ, टाइप को बदलकर git रिपॉज़िटरी का इस्तेमाल किया जा सकता है:
        • type: git_repository
        • https://bazel.build/rules/lib/repo/git पर बताए गए ये फ़ील्ड:
          • remote
          • commit
          • shallow_since
          • tag
          • init_submodules
          • verbose
          • strip_prefix
      • टाइप को बदलकर लोकल पाथ का इस्तेमाल किया जा सकता है. यह local_repository रेपो को दिखाता है. इसमें ये फ़ील्ड होते हैं:
        • type: local_path
        • 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 गड़बड़ी का मैसेज दिखाएगा
    • patches/: यह एक वैकल्पिक डायरेक्ट्री है. इसमें पैच फ़ाइलें होती हैं. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json का टाइप "archive" हो

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 जोड़कर इसे फिर से जोड़ा जा सकता है.