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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 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 फ़ाइल. ध्यान दें कि यह MODULE.bazel फ़ाइल, Bazel की बाहरी डिपेंडेंसी को हल करने के दौरान पढ़ी जाती है, न कि सोर्स संग्रह से (जब तक कि नॉन-रजिस्ट्री बदलाव न हो). यह भी ध्यान दें कि रिलीज़ का वर्शन सेट करने के लिए, इस फ़ाइल का इस्तेमाल करना सबसे अच्छा होता है. साथ ही, सोर्स संग्रह MODULE.bazel फ़ाइल में ऐसा करने से बचें. मॉड्यूल के वर्शन के बारे में ज़्यादा जानने के लिए, अक्सर पूछे जाने वाले सवाल देखें.
    • source.json: इस मॉड्यूल वर्शन के सोर्स को फ़ेच करने के तरीके के बारे में जानकारी देने वाली JSON फ़ाइल
    • patches/: पैच फ़ाइलों वाली वैकल्पिक डायरेक्ट्री. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json का टाइप "संग्रह" हो
    • overlay/: ओवरले फ़ाइलों वाली वैकल्पिक डायरेक्ट्री. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json का टाइप "संग्रह" हो

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 रिपॉज़िटरी नियम के तहत बैक अप किया जाता है. इसे किसी दिए गए यूआरएल से संग्रह डाउनलोड करके और उसके कॉन्टेंट को निकालकर फ़ेच किया जाता है. यह इन फ़ील्ड के साथ काम करता है:
    • url: सोर्स संग्रह का यूआरएल, एक स्ट्रिंग
    • mirror_urls: सोर्स संग्रह के मिरर यूआरएल की स्ट्रिंग की सूची. url के बाद, यूआरएल को बैकअप के तौर पर क्रम से आज़माया जाता है.
    • integrity: स्ट्रिंग, संग्रह का सब-रिसोर्स इंटिग्रिटी चेकसम
    • strip_prefix: एक स्ट्रिंग, सोर्स संग्रह को निकालते समय डायरेक्ट्री का प्रीफ़िक्स हटाने के लिए
    • overlay: एक JSON ऑब्जेक्ट, जिसमें एक्सट्रैक्ट किए गए संग्रह के ऊपर लेयर करने के लिए ओवरले फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/overlay डायरेक्ट्री में मौजूद होती हैं. कुंजियां, ओवरले फ़ाइल के नाम होती हैं और वैल्यू, ओवरले फ़ाइलों के इंटिग्रिटी चेकसम होती हैं. ओवरले, पैच फ़ाइलों से पहले लागू किए जाते हैं.
    • patches: एक JSON ऑब्जेक्ट, जिसमें पैच फ़ाइलें होती हैं. इन्हें, निकाले गए संग्रह पर लागू किया जाता है. पैच फ़ाइलें, /modules/$MODULE/$VERSION/patches डायरेक्ट्री में मौजूद होती हैं. कुंजियां, पैच फ़ाइल के नाम होती हैं और वैल्यू, पैच फ़ाइलों के इंटिग्रिटी चेकसम होती हैं. पैच, ओवरले फ़ाइलों के बाद और patches में दिखने के क्रम में लागू किए जाते हैं.
    • patch_strip: कोई संख्या; यह यूनिक्स patch के --strip आर्ग्युमेंट जैसी ही होती है.
    • archive_type: स्ट्रिंग, डाउनलोड की गई फ़ाइल का संग्रह टाइप (http_archive पर type जैसा ही).
  • अगर type git_repository है, तो इस मॉड्यूल वर्शन का बैक अप, git_repository डेटा स्टोर करने की जगह के नियम से लिया जाता है. इसे Git डेटा स्टोर करने की जगह को क्लोन करके फ़ेच किया जाता है.
    • ये फ़ील्ड इस्तेमाल किए जा सकते हैं और इन्हें सीधे git_repository repo नियम पर भेजा जाता है: 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 सेंट्रल रजिस्ट्री

https://bcr.bazel.build/ पर मौजूद Bazel Central Registry (BCR), एक इंडेक्स रजिस्ट्री है. इसमें GitHub रिपॉज़िटरी bazelbuild/bazel-central-registry से मिले कॉन्टेंट का डेटा होता है. https://registry.bazel.build/ पर वेब फ़्रंटएंड का इस्तेमाल करके, इसके कॉन्टेंट को ब्राउज़ किया जा सकता है.

Bazel कम्यूनिटी, बीसीआर को मैनेज करती है. योगदान देने वाले लोग, पुश अनुरोध सबमिट कर सकते हैं. बीसीआर में योगदान देने के दिशा-निर्देश देखें.

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

रजिस्ट्री चुनना

बार-बार इस्तेमाल किए जा सकने वाले 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 जोड़कर इसे फिर से जोड़ा जा सकता है.