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

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

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

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

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

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

• /bazel_registry.json: एक JSON फ़ाइल जिसमें रजिस्ट्री के लिए मेटाडेटा शामिल होता है. जैसे:
  • mirrors: सोर्स संग्रहों के लिए इस्तेमाल करने के लिए मिरर की सूची तय करना. मिरर किया गया यूआरएल, मिरर को आपस में जोड़ता है. साथ ही, मॉड्यूल का सोर्स यूआरएल, जिसे इसकी source.json फ़ाइल Sans प्रोटोकॉल ने तय किया है. उदाहरण के लिए, अगर किसी मॉड्यूल का सोर्स यूआरएल https://foo.com/bar/baz है और mirrors में ["https://mirror1.com/", "https://example.com/mirror2/"] शामिल है, तो Baज़ल इन यूआरएल को क्रम से आज़माने की कोशिश करेगा: 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 फ़ाइल जिसमें मॉड्यूल के इस वर्शन का सोर्स फ़ेच करने का तरीका बताया गया है
    • डिफ़ॉल्ट तौर पर, "संग्रह" टाइप होता है. यह 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".
    • GitHub डेटा स्टोर करने की जगह का इस्तेमाल करने के लिए, टाइप को बदला जा सकता है. इसमें इन फ़ील्ड का इस्तेमाल किया जाएगा:
      • type: git_repository
      • इन फ़ील्ड के बारे में https://bazu.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> के ज़रिए इस्तेमाल किया जाना चाहिए. ऐसा नहीं करने पर, Bagel एक गड़बड़ी दिखाएगा
  • patches/: पैच फ़ाइलों वाली एक वैकल्पिक डायरेक्ट्री, जिसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json में "संग्रह" टाइप होता है

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

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

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

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

रजिस्ट्री चुनी जा रही हैं

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

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

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