Build Foundation ने फ़ाउंडिंग सदस्यों के तौर पर लोगों को शामिल करना शुरू कर दिया है! ईमेल पाने वाली सूची में शामिल हों, रिसर्च में हिस्सा लेने से जुड़ा कानूनी समझौता पढ़ें, और रजिस्टर करें!

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

समस्या की शिकायत करें सोर्स देखें

Nightly · 9.2 · 9.1 · 9.0 · 8.7 · 8.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: यह इस मॉड्यूल के yanked versions वर्शन का मैप होता है. कुंजियां, yank करने के लिए वर्शन होनी चाहिए. वहीं, वैल्यू में यह जानकारी होनी चाहिए कि वर्शन को yank क्यों किया गया है. इसमें ज़्यादा जानकारी के लिए लिंक भी शामिल होना चाहिए
/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: यह डाउनलोड की गई फ़ाइल का संग्रह टाइप होता है. यह type पर मौजूद http_archive जैसा होता है. डिफ़ॉल्ट तौर पर, संग्रह का टाइप, यूआरएल के फ़ाइल एक्सटेंशन से तय होता है. अगर फ़ाइल का कोई एक्सटेंशन नहीं है, तो इनमें से कोई एक एक्सटेंशन साफ़ तौर पर बताया जा सकता है: "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 ऑब्जेक्ट होता है. इसमें इस मॉड्यूल के yanked versions वर्शन की जानकारी शामिल होती है. कुंजियां, yank करने के लिए वर्शन होनी चाहिए. वहीं, वैल्यू में यह जानकारी होनी चाहिए कि वर्शन को yank क्यों किया गया है. इसमें ज़्यादा जानकारी के लिए लिंक भी शामिल होना चाहिए.

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

`source.json`

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

अगर type की वैल्यू archive है (डिफ़ॉल्ट वैल्यू), तो इस मॉड्यूल वर्शन को http_archive रेपो नियम से बैक अप किया जाता है. इसे किसी दिए गए यूआरएल से संग्रह डाउनलोड करके और उसके कॉन्टेंट को एक्सट्रैक्ट करके पाया जाता है. इसमें ये फ़ील्ड शामिल होते हैं:
- url: यह एक स्ट्रिंग होती है. यह सोर्स संग्रह का यूआरएल होता है
- mirror_urls: यह स्ट्रिंग की एक सूची होती है. यह सोर्स संग्रह के मिरर यूआरएल होते हैं. बैकअप के तौर पर, url के बाद यूआरएल को क्रम से आज़माया जाता है.
- 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 पर मौजूद http_archive जैसा होता है.
अगर type की वैल्यू git_repository है, तो इस मॉड्यूल वर्शन को git_repository रेपो नियम से बैक अप किया जाता है. इसे 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 कम्यूनिटी, BCR का रखरखाव करती है. इसमें योगदान देने वाले लोग, पुल अनुरोध सबमिट कर सकते हैं. बीसीआर में योगदान देने के लिए दिशा-निर्देश देखें.

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

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

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

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

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