वेंडर मोड

वेंडर मोड, Bzlmod की एक सुविधा है. इसकी मदद से, बाहरी डिपेंडेंसी की लोकल कॉपी बनाई जा सकती है. यह ऑफ़लाइन बिल्ड के लिए मददगार होता है. इसके अलावा, यह तब भी फ़ायदेमंद होता है, जब आपको किसी बाहरी डिपेंडेंसी के सोर्स को कंट्रोल करना हो.

वेंडर मोड चालू करना

--vendor_dir फ़्लैग तय करके, वेंडर मोड चालू किया जा सकता है.

उदाहरण के लिए, इसे अपनी .bazelrc फ़ाइल में जोड़कर:

# Enable vendor mode with vendor directory under <workspace>/vendor_src
common --vendor_dir=vendor_src

वेंडर डायरेक्ट्री, आपके वर्कस्पेस रूट का रिलेटिव पाथ या एब्सोल्यूट पाथ हो सकती है.

खास बाहरी रिपॉज़िटरी (डेटा स्टोर करने की जगह) वेंडर

--repo फ़्लैग के साथ vendor कमांड का इस्तेमाल करके, यह तय किया जा सकता है कि किस रिपॉज़िटरी को वेंडर को भेजना है. यह कैनोनिकल रिपॉज़िटरी का नाम और सामान्य रिपॉज़िटरी का नाम, दोनों को स्वीकार करता है.

उदाहरण के लिए, ये काम करने पर:

bazel vendor --vendor_dir=vendor_src --repo=@rules_cc

या

bazel vendor --vendor_dir=vendor_src --repo=@@rules_cc+

को <workspace root>/vendor_src/rules_cc+ के तहत, rules_cc को वेंडर के तौर पर इस्तेमाल करने की अनुमति मिलेगी.

दिए गए टारगेट के लिए वेंडर की बाहरी डिपेंडेंसी

दिए गए टारगेट पैटर्न बनाने के लिए ज़रूरी सभी बाहरी डिपेंडेंसी को वेंडर करने के लिए, bazel vendor <target patterns> को चलाया जा सकता है.

उदाहरण के लिए

bazel vendor --vendor_dir=vendor_src //src/main:hello-world //src/test/...

//src/main:hello-world टारगेट बनाने के लिए ज़रूरी सभी डेटा स्टोर करने की प्रोसेस को वेंडर करेगा. साथ ही, मौजूदा कॉन्फ़िगरेशन के साथ //src/test/... से जुड़े सभी टारगेट को स्टोर करेगा.

टारगेट पैटर्न का विश्लेषण करने के लिए, यह bazel build --nobuild कमांड इस्तेमाल कर रहा है. इसलिए, इस कमांड पर बिल्ड फ़्लैग लागू किए जा सकते हैं और नतीजे पर असर पड़ सकता है.

टारगेट को ऑफ़लाइन बनाना

वेंडर की ओर से उपलब्ध कराई गई बाहरी डिपेंडेंसी की मदद से, टारगेट को ऑफ़लाइन बनाया जा सकता है. इसके लिए,

bazel build --vendor_dir=vendor_src //src/main:hello-world //src/test/...

यह ज़रूरी है कि बिल्ड, नेटवर्क ऐक्सेस और रिपॉज़िटरी कैश मेमोरी के बिना, बिल्ड के लिए बनाए गए किसी नए एनवायरमेंट में काम करे.

इसलिए, आपके पास वेंडर वाले सोर्स की जांच करके, उन्हें किसी दूसरी मशीन पर ऑफ़लाइन बनाने का विकल्प होना चाहिए.

वेंडर की सभी बाहरी डिपेंडेंसी

ट्रांज़िशन वाली बाहरी डिपेंडेंसी के ग्राफ़ में मौजूद सभी रिपॉज़िटरी को वेंडर के तौर पर जोड़ने के लिए, ये काम किए जा सकते हैं:

bazel vendor --vendor_dir=vendor_src

ध्यान दें कि सभी डिपेंडेंसी को वेंडर करने के कुछ नुकसान हैं:

• सभी रिपॉज़िटरी को फ़ेच करने में समय लग सकता है. इनमें, ट्रांज़िटिव तरीके से जोड़े गए रिपॉज़िटरी भी शामिल हैं.
• वेंडर डायरेक्ट्री बहुत बड़ी हो सकती है.
• अगर कुछ रिपॉज़िटरी, मौजूदा प्लैटफ़ॉर्म या एनवायरमेंट के साथ काम नहीं करते, तो हो सकता है कि उन्हें फ़ेच न किया जा सके.

इसलिए, खास टारगेट के लिए पहले वेंडर बनाने पर विचार करें.

VENDOR.bazel की मदद से वेंडर मोड कॉन्फ़िगर करना

आपके पास यह कंट्रोल करने का विकल्प है कि वेंडर डायरेक्ट्री में मौजूद Seller.baकोई फ़ाइल के साथ, दिए गए रिपो को कैसे मैनेज किया जाए.

दो डायरेक्टिव उपलब्ध हैं. दोनों में, आर्ग्युमेंट के तौर पर कैननिकल रिपॉज़िटरी के नाम की सूची स्वीकार की जाती है:

• ignore(): वेंडर मोड से किसी रिपॉज़िटरी को पूरी तरह से अनदेखा करने के लिए.
• pin(): किसी रिपॉज़िटरी को उसके मौजूदा वेंडर सोर्स पर पिन करने के लिए, जैसे कि इस रिपॉज़िटरी के लिए --override_repository फ़्लैग हो. वेंडर कमांड चलाने के दौरान, Bazel इस रिपॉज़िटरी के लिए वेंडर किए गए सोर्स को तब तक अपडेट नहीं करेगा, जब तक उसे अनपिन नहीं किया जाता. इस रेपो के लिए उपयोगकर्ता, वेंडर सोर्स में बदलाव कर सकता है और उसका रखरखाव कर सकता है.

उदाहरण के लिए

ignore("@@rules_cc+")
pin("@@bazel_skylib+")

इस कॉन्फ़िगरेशन के साथ

• दोनों रिपॉज़िटरी को वेंडर के बाद के निर्देशों से बाहर रखा जाएगा.
• Repo bazel_skylib को वेंडर डायरेक्ट्री में मौजूद सोर्स से बदल दिया जाएगा.
• उपयोगकर्ता, bazel_skylib के वेंडर सोर्स में सुरक्षित तरीके से बदलाव कर सकता है.
• bazel_skylib को फिर से वेंडर के तौर पर जोड़ने के लिए, उपयोगकर्ता को पहले पिन स्टेटमेंट को बंद करना होगा.

वेंडर मोड के काम करने का तरीका समझना

Bazel, $(bazel info output_base)/external में मौजूद किसी प्रोजेक्ट की बाहरी डिपेंडेंसी फ़ेच करता है. बाहरी डिपेंडेंसी को वेंडर के तौर पर जोड़ने का मतलब है कि काम की फ़ाइलों और डायरेक्ट्री को वेंडर की दी गई डायरेक्ट्री में ले जाना. साथ ही, बाद के बिल्ड के लिए वेंडर के सोर्स का इस्तेमाल करना.

वेंडर को बेचे जाने वाले कॉन्टेंट में ये चीज़ें शामिल हैं:

• रिपॉज़िटरी डायरेक्ट्री
• रिपॉज़िटरी मार्कर फ़ाइल

अगर किसी बिल्ड के दौरान, वेंडर की मार्कर फ़ाइल अप-टू-डेट है या रीपो को VENDOR.bazel फ़ाइल में पिन किया गया है, तो Bazel, रीपोज़िटरी नियम को चलाने के बजाय, $(bazel info output_base)/external में इसके लिए एक सिमलिंक बनाकर, वेंडर के सोर्स का इस्तेमाल करता है. ऐसा न होने पर, चेतावनी दी जाती है और Bazel, रिपॉज़िटरी का नया वर्शन फ़ेच करने के लिए फ़ॉलबैक करेगा.

वेंडर की रजिस्ट्री फ़ाइलें

बाहरी डिपेंडेंसी फ़ेच करने के लिए, Bazel को Bazel मॉड्यूल रिज़ॉल्यूशन की प्रोसेस पूरी करनी होती है. इसके लिए, इंटरनेट के ज़रिए रजिस्ट्री फ़ाइलों को ऐक्सेस करना पड़ सकता है. ऑफ़लाइन बिल्ड करने के लिए, Bazel वेंडर नेटवर्क से फ़ेच की गई सभी रजिस्ट्री फ़ाइलों को <vendor_dir>/_registries डायरेक्ट्री में सेव करते हैं.

वेंडर के सिमलिंक

बाहरी रिपॉज़िटरी में, अन्य फ़ाइलों या डायरेक्ट्री पर ले जाने वाले सिंबललिंक हो सकते हैं. यह पक्का करने के लिए कि सिंबललिंक सही तरीके से काम करें, Bazel वेंडर के सोर्स में सिंबललिंक को फिर से लिखने के लिए, इस रणनीति का इस्तेमाल करता है:

• <vendor_dir>/bazel-external पर ले जाने वाला सिमलिंक बनाएं, जो $(bazel info output_base)/external पर ले जाता हो. यह हर Bazel कमांड के हिसाब से अपने-आप रीफ़्रेश होता है.
• वेंडर सोर्स के लिए, उन सभी सिंकलिंक को फिर से लिखें जो मूल रूप से $(bazel info output_base)/external के तहत मौजूद पाथ पर ले जाते हैं. इन्हें <vendor_dir>/bazel-external के तहत मौजूद रिलेटिव पाथ पर ले जाएं.

उदाहरण के लिए, अगर ओरिजनल सिंबललिंक

<vendor_dir>/repo_foo+/link  =>  $(bazel info output_base)/external/repo_bar+/file

इसे इस तरह से फिर से लिखा जाएगा

<vendor_dir>/repo_foo+/link  =>  ../../bazel-external/repo_bar+/file

कहां

<vendor_dir>/bazel-external  =>  $(bazel info output_base)/external  # This might be new if output base is changed

<vendor_dir>/bazel-external, Bazel की मदद से अपने-आप जनरेट होता है. इसलिए, हमारा सुझाव है कि इसे .gitignore या इससे मिलते-जुलते फ़ंक्शन में जोड़ें, ताकि इसे चेक इन न करना पड़े.

इस रणनीति के तहत, वेंडर सोर्स को किसी दूसरी जगह पर ले जाने या bazel आउटपुट बेस में बदलाव करने के बाद भी, वेंडर सोर्स में मौजूद सिंबललिंक सही तरीके से काम करते रहेंगे.