Bzlmod, Bazel रजिस्ट्री से उनकी जानकारी का अनुरोध करके, डिपेंडेंसी का पता लगाता है: ये Bazel मॉड्यूल के डेटाबेस होते हैं. फ़िलहाल, Bzlmod सिर्फ़ इंडेक्स रजिस्ट्री के साथ काम करता है. ये रजिस्ट्री, किसी खास फ़ॉर्मैट का इस्तेमाल करने वाली लोकल डायरेक्ट्री या स्टैटिक एचटीटीपी सर्वर होती हैं.
इंडेक्स रजिस्ट्री
इंडेक्स रजिस्ट्री, एक लोकल डायरेक्ट्री या स्टैटिक एचटीटीपी सर्वर होती है. इसमें मॉड्यूल की सूची के बारे में जानकारी होती है. जैसे, उनका होम पेज, उन्हें मैनेज करने वाले लोग, हर वर्शन की MODULE.bazel
फ़ाइल, और हर वर्शन का सोर्स फ़ेच करने का तरीका. ध्यान दें, इसे सोर्स के संग्रह खुद उपलब्ध कराने की ज़रूरत नहीं है.
इंडेक्स रजिस्ट्री इस फ़ॉर्मैट में होनी चाहिए:
/bazel_registry.json
: रजिस्ट्री का मेटाडेटा रखने वाली JSON फ़ाइल, जैसे कि:mirrors
: सोर्स संग्रह के लिए इस्तेमाल किए जाने वाले मिरर की सूची तय करना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
: यह Unixpatch
के--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
का टाइप "संग्रह" हो
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
जोड़कर इसे फिर से जोड़ा जा सकता है.