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: यह इस मॉड्यूल के हटाए गए वर्शन का मैप होता है. कुंजियां, हटाए जाने वाले वर्शन होने चाहिए. वहीं, वैल्यू में यह जानकारी होनी चाहिए कि वर्शन को क्यों हटाया गया है. इसमें ज़्यादा जानकारी का लिंक भी शामिल होना चाहिए
/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: यह डाउनलोड की गई फ़ाइल का संग्रह टाइप होता है. यह 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" हो

Bazel Central Registry

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

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

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

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

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

अगर आपकी रजिस्ट्री 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 जोड़कर, इसे वापस जोड़ा जा सकता है.