वेंडर मोड, Bzlmod की एक सुविधा है. इसकी मदद से, बाहरी डिपेंडेंसी. यह ऑफ़लाइन बिल्ड या आपको बाहरी डिपेंडेंसी का सोर्स कंट्रोल कर सकते हैं.
वेंडर मोड चालू करें
--vendor_dir फ़्लैग तय करके, वेंडर मोड चालू किया जा सकता है.
उदाहरण के लिए, इसे अपनी .bazelrc फ़ाइल में जोड़कर:
# Enable vendor mode with vendor directory under <workspace>/vendor_src
common --vendor_dir=vendor_src
वेंडर डायरेक्ट्री, आपके फ़ाइल फ़ोल्डर रूट से मिलती-जुलती पाथ हो सकती है या ऐब्सलूट पाथ.
खास बाहरी रिपॉज़िटरी (डेटा स्टोर करने की जगह) वेंडर
--repo फ़्लैग के साथ vendor कमांड का इस्तेमाल करके यह तय किया जा सकता है कि कौनसा रेपो
साथ ही, यह कैननिकल रेपो, दोनों तरह के दस्तावेज़ों को स्वीकार करता है
name और पेपर रेपो
name.
उदाहरण के लिए, चलाना:
bazel vendor --vendor_dir=vendor_src --repo=@rules_cc
या
bazel vendor --vendor_dir=vendor_src --repo=@@rules_cc~
क्या दोनों को इसके तहत वेंडर बनाने के लिए,Rule_cc दी जाएगी
<workspace root>/vendor_src/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
ध्यान दें कि सभी डिपेंडेंसी के वेंडर के कुछ नुकसान होते हैं:
- इस तरह के सभी डेटा को फ़ेच करने में काफ़ी समय लग सकता है. इनमें वे रिपोज़ भी शामिल हैं जिन्हें एक जगह से दूसरी जगह भेजा जाता है.
- वेंडर डायरेक्ट्री बहुत बड़ी हो सकती है.
- अगर कुछ डेटा स्टोर करने की जगह, मौजूदा प्लैटफ़ॉर्म या एनवायरमेंट के साथ काम नहीं करती है, तो हो सकता है कि वे फ़ेच न हो पाएं.
इसलिए, खास टारगेट के लिए पहले वेंडर बनाने पर विचार करें.
वेंडर मोड को FORMAT.bazu के साथ कॉन्फ़िगर करें
आपके पास यह कंट्रोल करने का विकल्प है कि पर जाएं.
यहां दो निर्देश उपलब्ध हैं, जिनमें आर्ग्युमेंट के तौर पर, कैननिकल रेपो नाम:
ignore(): वेंडर मोड से डेटा स्टोर करने की जगह को पूरी तरह से अनदेखा करने के लिए.pin(): रिपॉज़िटरी को उसके मौजूदा वेंडर वाले सोर्स में पिन करने के लिए, जैसे कि कोई इस डेटा स्टोर करने की जगह के लिए--override_repositoryफ़्लैग. Basel, वेंडर को अपडेट नहीं करेगा सोर्स के तौर पर सेव कर सकते हैं. इस रेपो के लिए उपयोगकर्ता, वेंडर सोर्स में बदलाव कर सकता है और उसका रखरखाव कर सकता है.
उदाहरण के लिए
ignore("@@rules_cc~")
pin("@@bazel_skylib~")
इस कॉन्फ़िगरेशन के साथ
- दोनों रेपो को, आने वाले वेंडर निर्देशों में शामिल नहीं किया जाएगा.
- रेपो
bazel_skylibको इसके नीचे मौजूद सोर्स से बदल दिया जाएगा वेंडर डायरेक्ट्री. - उपयोगकर्ता,
bazel_skylibके वेंडर सोर्स में सुरक्षित तरीके से बदलाव कर सकता है. bazel_skylibको फिर से वेंडर बनाने के लिए, उपयोगकर्ता को पिन स्टेटमेंट बंद करना होगा चुनें.
जानें कि वेंडर मोड कैसे काम करता है
Basel, $(bazel info
output_base)/external के तहत आने वाले प्रोजेक्ट की बाहरी डिपेंडेंसी को फ़ेच करता है. एक्सटर्नल डिपेंडेंसी वेंडर बनाने का मतलब है कि कंपनी से बाहर निकलना
संबंधित फ़ाइलें और डायरेक्ट्री दी गई वेंडर डायरेक्ट्री में अपलोड करने के बाद,
वेंडर के तौर पर बनाया गया.
वेंडर किए जा रहे कॉन्टेंट में ये चीज़ें शामिल हैं:
- रेपो डायरेक्ट्री
- रेपो मार्कर फ़ाइल
बिल्ड के दौरान, अगर वेंडर की मार्कर फ़ाइल अप-टू-डेट है या रेपो
विक्रेता.बेज़ेल फ़ाइल में पिन की गई है, तो बेज़ेल
असल में, $(bazel info output_base)/external से कम कीमत में सिमलिंक
डेटा स्टोर करने की जगह का नियम लागू कर रहा है. अन्यथा, एक चेतावनी प्रिंट कर दी जाएगी और Bagel होगा
फ़ॉलबैक का सबसे नया वर्शन फ़ेच करें.
वेंडर की रजिस्ट्री फ़ाइलें
बाहरी डेटा फ़ेच करने के लिए, Bazu को बेज़ल मॉड्यूल का रिज़ॉल्यूशन पूरा करना होता है
डिपेंडेंसी के लिए, इंटरनेट से रजिस्ट्री फ़ाइलों को ऐक्सेस करना पड़ सकता है. यहां की यात्रा पर हूं
ऑफ़लाइन बिल्ड पाने के साथ ही, बेज़ेल वेंडर से सभी रजिस्ट्री फ़ाइलों को फ़ेच किया गया
<vendor_dir>/_registries डायरेक्ट्री के तहत काम करने वाला नेटवर्क.
वेंडर के सिमलिंक
बाहरी डेटा स्टोर करने की जगहों में दूसरी फ़ाइलों पर ले जाने वाले सिमलिंक हो सकते हैं या डायरेक्ट्री में जा सकते हैं. यह पक्का करने के लिए कि सिमलिंक सही तरीके से काम करें, Basel का तरीका वेंडर सोर्स में सिमलिंक को फिर से लिखने की रणनीति:
- ऐसा सिमलिंक बनाएं
<vendor_dir>/bazel-externalजो$(bazel info output_base)/externalपर ले जाता हो. इसे हर बेज़ल कमांड के हिसाब से रीफ़्रेश किया जाता है स्वचालित रूप से. - वेंडर वाले सोर्स के लिए, उन सभी सिमलिंक को फिर से लिखें जो मूल रूप से
$(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 को Basel ने अपने-आप जनरेट किया है. इसलिए, यह
इसे चेक इन करने से बचने के लिए, इसे .gitignore या इसके बराबर जोड़ने का सुझाव दिया जाता है.
इस रणनीति के साथ, वेंडर वाले सोर्स में मौजूद सिमलिंक सही तरीके से काम करेंगे, वेंडर वाले सोर्स को किसी दूसरी जगह या बेज़ल आउटपुट बेस पर ले जाने के बाद बदल जाता है.