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

एक रात का किराया · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

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: सोर्स संग्रह का यूआरएल
    - 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" हो

`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][subresource-integrity] चेकसम
- strip_prefix: एक स्ट्रिंग, सोर्स संग्रह को निकालते समय डायरेक्ट्री प्रीफ़िक्स को हटाने के लिए
- overlay: यह एक JSON ऑब्जेक्ट है. इसमें एक्सट्रैक्ट किए गए संग्रह के ऊपर लेयर करने के लिए ओवरले फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/overlay डायरेक्ट्री में मौजूद होती हैं. कुंजियां, ओवरले फ़ाइल के नाम होती हैं और वैल्यू, ओवरले फ़ाइलों के इंटिग्रिटी चेकसम होते हैं. पैच फ़ाइलों से पहले ओवरले लागू किए जाते हैं.
- patches: यह एक JSON ऑब्जेक्ट है. इसमें एक्सट्रैक्ट किए गए संग्रह पर लागू करने के लिए पैच फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/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 जोड़कर इसे फिर से जोड़ा जा सकता है.