वेंडर मोड

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

वेंडर मोड, 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 की मदद से वेंडर मोड कॉन्फ़िगर करना

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

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

  • 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 आउटपुट बेस में बदलाव करने के बाद भी, वेंडर सोर्स में मौजूद सिंबललिंक सही तरीके से काम करते रहेंगे.