Basel मॉड्यूल एक Basel प्रोजेक्ट है. इसके कई वर्शन हो सकते हैं, जिनमें से हर एक जो दूसरे मॉड्यूल के बारे में मेटाडेटा पब्लिश करता है. यह है यह दूसरे डिपेंडेंसी मैनेजमेंट सिस्टम में जाने-पहचाने कॉन्सेप्ट से मिलता-जुलता है, जैसे कि Maven आर्टफ़ैक्ट, एक एनपीएम पैकेज, Go मॉड्यूल या कार्गो क्रेट.
मॉड्यूल के रेपो रूट में एक MODULE.bazel फ़ाइल होनी चाहिए (जिसके बगल में
WORKSPACE फ़ाइल). यह फ़ाइल, मॉड्यूल की मेनिफ़ेस्ट फ़ाइल है. इसमें इसका नाम बताया जाता है
वर्शन, डायरेक्ट डिपेंडेंसी की सूची, और अन्य जानकारी शामिल है. बुनियादी
उदाहरण:
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
MODULE.bazel फ़ाइलों में उपलब्ध निर्देशों की पूरी सूची देखें.
मॉड्यूल रिज़ॉल्यूशन निष्पादित करने के लिए, Baज़र, रूट मॉड्यूल के
MODULE.bazel फ़ाइल का इस्तेमाल करता है और फिर बार-बार किसी डिपेंडेंसी की
Basel रजिस्ट्री से तब तक फ़ाइल MODULE.bazel
पूरा डिपेंडेंसी ग्राफ़ खोजता है.
डिफ़ॉल्ट रूप से, Basel हर मॉड्यूल का एक वर्शन चुनता है इस्तेमाल करें. Baज़ल, हर मॉड्यूल के लिए रेपो की जानकारी देता है और रजिस्ट्री से सलाह लेता है ताकि हर स्टोर को साफ़ तौर पर बताया जा सके.
वर्शन का फ़ॉर्मैट
बेज़ल का नेटवर्क काफ़ी अलग है. प्रोजेक्ट में अलग-अलग तरह के वर्शन बनाने के तरीकों का इस्तेमाल किया जाता है. कॉन्टेंट बनाने
अब तक SemVer सबसे लोकप्रिय है, लेकिन कुछ
प्रोजेक्ट पर काम करने के लिए,
अब्सील,
वर्शन तारीख के हिसाब से हों, जैसे कि 20210324.2).
इस वजह से, Bzlmod SemVer स्पेसिफ़िकेशन का ज़्यादा आसान वर्शन इस्तेमाल करता है. कॉन्टेंट बनाने अंतरों में शामिल हैं:
- SemVer का कहना है कि "रिलीज़" वर्शन के हिस्से के तौर पर,
सेगमेंट:
MAJOR.MINOR.PATCH. Basel में, इस ज़रूरत को ढीला कर दिया गया है, इसलिए कितने भी सेगमेंट की अनुमति हो. - SemVer में, "रिलीज़" के हर सेगमेंट भाग में केवल अंक होने चाहिए. Basel में, इसे लैंगिक जानकारी के लिए ढीला किया गया है, ताकि सिमेंटिक्स "आइडेंटिफ़ायर" से मेल खाता है "प्रीरिलीज़" में .
- इसके अलावा, मेजर, माइनर, और पैच वर्शन में होने वाले बदलावों की वजह से लागू नहीं किया जाता. हालांकि, इसके लिए कंपैटबिलिटी लेवल देखें हम पुराने सिस्टम के साथ काम करने की सुविधा को कैसे दिखाते हैं.
SemVer का कोई भी मान्य वर्शन, Basel मॉड्यूल का एक मान्य वर्शन है. इसके अलावा, दो
SemVer के वर्शन a और b की तुलना a < b से तब ही हो सकती है, जब दोनों वर्शन एक ही हों. ऐसा तब होता है, जब
उनकी तुलना बेज़ेल मॉड्यूल वर्शन से की जाती है.
वर्शन चुनना
डायमंड डिपेंडेंसी से जुड़ी समस्या को ध्यान में रखें. यह वर्शन वाली डिपेंडेंसी का मुख्य विकल्प है मैनेजमेंट स्पेस मान लें कि आपके पास डिपेंडेंसी ग्राफ़ है:
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
D के किस वर्शन का इस्तेमाल किया जाना चाहिए? इस प्रश्न का समाधान करने के लिए, Bzlmod द्वारा
कम से कम वर्शन चुनना
(MVS) एल्गोरिदम को Go मॉड्यूल सिस्टम में लॉन्च किया गया. MVS का मानना है कि सभी नए
मॉड्यूल के वर्शन पुराने सिस्टम के साथ काम करते हैं. इसलिए, किसी मॉड्यूल के वर्शन को चुना जाता है.
किसी भी आश्रित द्वारा दर्ज (हमारे उदाहरण में D 1.1). इसे "मिनिमल" कहा जाता है
क्योंकि D 1.1 सबसे पुराना वर्शन है जो हमारी ज़रूरी शर्तों को पूरा कर सकता है —
D 1.2 या इसके बाद की नई ऐसेट मौजूद होने पर भी, हम उन्हें नहीं चुनते. MVS का इस्तेमाल करने से
वर्शन चुनने की ऐसी प्रोसेस जो हाई-फ़िडेलिटी और फिर से जनरेट की जा सकती हो.
यांक किए गए वर्शन
अगर किसी वर्शन से बचना चाहिए, तो रजिस्ट्री इसे यां किया गया के तौर पर एलान कर सकती है
(जैसे, सुरक्षा से जुड़े जोखिम की आशंकाओं की वजह से). किसी फ़ाइल को चुनते समय, Baze ने गड़बड़ी की सूचना दी
मॉड्यूल का यैंक किया गया वर्शन. इस गड़बड़ी को ठीक करने के लिए, या तो नए वर्शन पर अपग्रेड करें,
का उपयोग किया जा सकता है या
--allow_yanked_versions
फ़्लैग का इस्तेमाल करें.
कंपैटिबिलिटी लेवल
Go में, पुराने सिस्टम के साथ काम करने की सुविधा के बारे में MVS का अनुमान इसलिए काम करता है, क्योंकि यह
किसी मॉड्यूल के पिछले वर्शन का, एक अलग मॉड्यूल के तौर पर काम न करना. इसके हिसाब से
SemVer है, इसका मतलब है कि A 1.x और A 2.x को अलग-अलग मॉड्यूल माना जाता है. इसकी मदद से ये काम किए जा सकते हैं
रिज़ॉल्व की गई डिपेंडेंसी ग्राफ़ में एक साथ मौजूद होना चाहिए. यही वजह है कि
मैं पैकेज पाथ में मेजर वर्शन को कोड में बदल रहा था
कंपाइल-टाइम या लिंकिंग-टाइम के विवाद.
हालांकि, Basel ऐसी गारंटी नहीं देता है, इसलिए इसे "मुख्य वर्शन" की ज़रूरत है
नंबर डालें, ताकि पुराने सिस्टम के साथ काम न करने वाले वर्शन का पता लगाया जा सके. इस नंबर पर कॉल किया गया है
कंपैटबिलिटी लेवल की मदद से सेट किया जाता है और इसे हर मॉड्यूल के वर्शन के हिसाब से,
module() डायरेक्टिव. इस जानकारी के साथ, Baज़र आपको गड़बड़ी का मैसेज दे सकता है,
यह पता लगाता है कि अलग-अलग लेवल के साथ एक ही मॉड्यूल के वर्शन का इस्तेमाल किया गया है या नहीं
रिज़ॉल्व की गई डिपेंडेंसी ग्राफ़ में मौजूद हो.
ओवरराइड
Basel के काम करने के तरीके में बदलाव करने के लिए, MODULE.bazel फ़ाइल में बदलावों के बारे में बताएं
मॉड्यूल रिज़ॉल्यूशन. सिर्फ़ रूट मॉड्यूल के ओवरराइड लागू होते हैं — अगर कोई मॉड्यूल
का इस्तेमाल एक डिपेंडेंसी के तौर पर किया जाता है, तो इसके ओवरराइड को अनदेखा कर दिया जाता है.
हर बदलाव एक खास मॉड्यूल नाम के लिए तय किया जाता है, जो इसकी सभी चीज़ों पर असर डालता है वर्शन मौजूद हैं. हालांकि, सिर्फ़ रूट मॉड्यूल के ओवरराइड की वजह से ये ट्रांज़िटिव डिपेंडेंसी के लिए हो सकते हैं, जो रूट मॉड्यूल में नहीं निर्भर करता है.
एक वर्शन में बदलाव
single_version_override
कई मकसद पूरे करता है:
versionएट्रिब्यूट की मदद से, किसी डिपेंडेंसी को किसी खास समयावधि पर पिन किया जा सकता है इस बात पर ध्यान दिए बिना कि डिपेंडेंसी के कौनसे वर्शन का अनुरोध किया गया है डिपेंडेंसी ग्राफ़.registryएट्रिब्यूट की मदद से, इस डिपेंडेंसी को ज़बरदस्ती किसी विशिष्ट रजिस्ट्री, सामान्य रजिस्ट्री का पालन करने के बजाय चुना गया प्रोसेस.patch*एट्रिब्यूट का इस्तेमाल करके, उन पैच का सेट तय किया जा सकता है जिन पर उन्हें लागू करना है को डाउनलोड किया गया है.
ये सभी एट्रिब्यूट ज़रूरी नहीं हैं. इन्हें एक-दूसरे के साथ मिलाया और मैच किया जा सकता है.
एक से ज़्यादा वर्शन ओवरराइड करने वाला वर्शन
multiple_version_override
को एक ही मॉड्यूल के कई वर्शन को एक साथ रहने की अनुमति देने के लिए
रिज़ॉल्व की गई डिपेंडेंसी ग्राफ़.
आप मॉड्यूल के लिए अनुमति वाले वर्शन की एक खास सूची बना सकते हैं, जिसमें ये सभी समाधान, समाधान से पहले डिपेंडेंसी ग्राफ़ में मौजूद होने चाहिए — यह भी ज़रूरी है कुछ, ट्रांज़िटिव डिपेंडेंसी होती है. यह अनुमति वाले हर वर्शन के हिसाब से तय होती है. इस तारीख के बाद रिज़ॉल्यूशन की पहचान की है, मॉड्यूल के अनुमति वाले वर्शन ही बचे हैं, जबकि Basel अपग्रेड मॉड्यूल के अन्य वर्शन से मिलते-जुलते, दोनों के लिए दिए गए सबसे नज़दीक वाले वर्शन में साथ काम करने की क्षमता का लेवल. अगर अनुमति वाला कोई नया वर्शन, डिवाइस के साथ काम नहीं करता है, तो लेवल मौजूद होने पर, बेज़ल एक गड़बड़ी की सूचना देता है.
उदाहरण के लिए, अगर 1.1, 1.3, 1.5, 1.7, और 2.0 वर्शन
समाधान से पहले डिपेंडेंसी ग्राफ़ और मेजर वर्शन के साथ काम करने की सुविधा
स्तर:
- एक से ज़्यादा वर्शन ओवरराइड करने से
1.3,1.7, और2.0नतीजे मिलेंगे1.1को1.3पर अपग्रेड किया जा रहा है.1.5को1.7और अन्य सदस्यताओं में अपग्रेड किया जा रहा है वर्शन में कोई बदलाव नहीं हुआ है. - एक से ज़्यादा वर्शन ओवरराइड करने से
1.5और2.0की वजह से गड़बड़ी होती है, जैसे कि1.7पर अपग्रेड करने के लिए, पुराने वर्शन के साथ काम करने के उसी लेवल का कोई नया वर्शन नहीं है. - एक से ज़्यादा वर्शन ओवरराइड करने से
1.9और2.0की वजह से गड़बड़ी होती है, जैसे कि समाधान से पहले, डिपेंडेंसी ग्राफ़ में1.9मौजूद नहीं है.
इसके अलावा, उपयोगकर्ता registry का इस्तेमाल करके भी रजिस्ट्री को बदल सकते हैं
विशेषता के आधार पर जोड़ा जा सकता है. यह सुविधा, सिंगल-वर्शन के बदलावों की तरह ही है.
गैर-रजिस्ट्री बदलावों की जानकारी
नॉन-रजिस्ट्री ओवरराइड की वजह से, वर्शन रिज़ॉल्यूशन से मॉड्यूल पूरी तरह हट जाता है. बेज़ल
रजिस्ट्री से इन MODULE.bazel फ़ाइलों का अनुरोध नहीं करता है, बल्कि
और इससे ऑनलाइन सुरक्षा नहीं मिलती.
Baज़ल, रजिस्ट्री के अलावा नीचे दिए गए बदलावों के साथ काम करते हैं:
ऐसे रिपोज तय करें जो बेज़ल मॉड्यूल न दिखाते हों
bazel_dep की मदद से, बेज़ल मॉड्यूल दिखाने वाले रेपो तय किए जा सकते हैं.
कभी-कभी ऐसे रेपो को बनाने की ज़रूरत होती है जो बेज़ल का प्रतिनिधित्व नहीं करता
module; उदाहरण के लिए, ऐसी फ़ाइल जिसमें एक सामान्य JSON फ़ाइल हो, जिसे डेटा के तौर पर पढ़ा जा सके.
इस मामले में, आप use_repo_rule का इस्तेमाल कर सकते हैं
निर्देश का इस्तेमाल, सीधे डेटा स्टोर करने की जगह तय करने के लिए किया गया है
रेपो नियम लागू करके. यह रेपो सिर्फ़ इसके मॉड्यूल को दिखेगा
परिभाषित किया गया है.
हुड के तहत, इसे मॉड्यूल जैसे ही तरीके का इस्तेमाल करके लागू किया जाता है एक्सटेंशन की मदद से, आप ज़्यादा जानकारी के साथ डेटा स्टोर करने की जगह तय कर सकते हैं ज़रूरत के हिसाब से इस्तेमाल किया जा सकता है.
डेटा स्टोर करने की जगहों के नाम और डिपार्टमेंट
उस डेटा स्टोर का साफ़ नाम जिसका इस्तेमाल करके,
मॉड्यूल अपने डायरेक्ट डिपेंडेंट होने के लिए डिफ़ॉल्ट रूप से मॉड्यूल नाम पर सेट होता है, जब तक कि
bazel_dep की repo_name विशेषता
डायरेक्टिव के बारे में कुछ और बताया गया है. ध्यान दें कि इसका मतलब है कि कोई मॉड्यूल
निर्भरता. यह
ट्रांज़िटिव डिपेंडेंसी.
उस रेपो का कैननिकल नाम जो
मॉड्यूल या तो module_name~version (उदाहरण के लिए, bazel_skylib~1.0.3) या module_name~ (उदाहरण के लिए, bazel_features~) है. यह इस बात पर निर्भर करता है कि
पूरे डिपेंडेंसी ग्राफ़ में मॉड्यूल के कई वर्शन (देखें
multiple_version_override).
ध्यान दें कि कैननिकल नाम का फ़ॉर्मैट ऐसा एपीआई नहीं है जिस पर आपको निर्भर रहना चाहिए और
इसमें किसी भी समय बदलाव किया जा सकता है. कैननिकल नाम को हार्ड-कोड करने के बजाय,
इसे सीधे Basel से लेने के लिए किसी सपोर्टेड तरीके का इस्तेमाल करना चाहिए:
* BUILD और .bzl फ़ाइलों में, इसका इस्तेमाल करें
Label इंस्टेंस पर Label.repo_name
यह डेटा, डेटा स्टोर करने की जगह के नाम से दिए गए लेबल स्ट्रिंग से बनता है. उदाहरण के लिए,
Label("@bazel_skylib").repo_name.
* रनफ़ाइल देखते समय, इसका इस्तेमाल करें
$(rlocationpath ...)
या किसी रनफ़ाइल लाइब्रेरी में से किसी एक
@bazel_tools//tools/{bash,cpp,java}/runfiles या, नियमसेट rules_foo के लिए,
@rules_foo//foo/runfiles में.
* IDE या भाषा जैसे किसी बाहरी टूल की मदद से Basel के साथ इंटरैक्ट करते समय
सर्वर, से मैपिंग करने के लिए bazel mod dump_repo_mapping कमांड का इस्तेमाल करें
डेटा स्टोर करने की जगहों के दिए गए सेट के कैननिकल नामों के लिए, साफ़ तौर पर दिए गए नाम.
मॉड्यूल एक्सटेंशन भी अतिरिक्त डेटा स्टोर कर सकते हैं के स्कोप में दिखता है.