एक्सटर्नल डिपेंडेंसी के बारे में खास जानकारी

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Baज़ल, बाहरी डिपेंडेंसी के साथ काम करता है. साथ ही, सोर्स फ़ाइलों (टेक्स्ट और बाइनरी, दोनों) का इस्तेमाल किया जा सकता है जो आपके फ़ाइल फ़ोल्डर में नहीं हैं. उदाहरण के लिए, वे GitHub के रेपो, Maven आर्टफ़ैक्ट या आपके लोकल स्टोर पर मौजूद डायरेक्ट्री में मशीन पर काम करता है.

Baze 6.0 के साथ, बाहरी डिपेंडेंसी को मैनेज करने के दो तरीके हैं: परंपरागत और रिपॉज़िटरी पर फ़ोकस करने वाला WORKSPACE सिस्टम और नया मॉड्यूल पर फ़ोकस करने वाला MODULE.bazel सिस्टम (कोडनाम Bzlmod, और --enable_bzlmod फ़्लैग के साथ चालू किया गया है). दो सिस्टम इस्तेमाल किए जा सकते हैं लेकिन Bzlmod चैनल, आने वाले समय में Basel में WORKSPACE सिस्टम की जगह ले रहा है रिलीज़ के लिए, Bzlmod माइग्रेशन गाइड देखें माइग्रेट करें.

यह दस्तावेज़, एक्सटर्नल डिपेंडेंसी मैनेजमेंट से जुड़े सिद्धांतों के बारे में बताता है पहले अपडेट किया है.

कॉन्सेप्ट

रिपॉज़िटरी

एक डायरेक्ट्री ट्री, जिसके रूट में सीमा मार्कर फ़ाइल मौजूद है. इसमें सोर्स शामिल है ऐसी फ़ाइलें जिनका इस्तेमाल बेज़ल बिल्ड में किया जा सकता है. आम तौर पर, इसे छोटा करके सिर्फ़ रेपो कर दिया जाता है.

रेपो बाउंड्री मार्कर की फ़ाइल, MODULE.bazel हो सकती है. इससे पता चलता है कि यह रेपो बेज़ेल मॉड्यूल को दिखाता है, REPO.bazel (नीचे देखें), या इसमें लेगसी कॉन्टेक्स्ट, WORKSPACE या WORKSPACE.bazel. कोई रेपो बाउंड्री मार्कर फ़ाइल डेटा स्टोर करने की जगह की सीमा को दिखाएगा; ऐसी कई फ़ाइलें एक साथ मौजूद हो सकती हैं डायरेक्ट्री.

डेटा स्टोर करने की मुख्य जगह

वह रिपॉज़िटरी जिसमें मौजूदा Basel कमांड चलाया जा रहा है.

फ़ाइल फ़ोल्डर

सभी Bagel कमांड से शेयर किया जाने वाला एनवायरमेंट, एक ही डेटा स्टोर करने की जगह में चलता है.

ध्यान दें कि ऐतिहासिक रूप से "डेटा स्टोर करने की जगह" की अवधारणाएं और "वर्कस्पेस" जा चुके हैं मिश्रित; "workspace" शब्द इसका इस्तेमाल अक्सर मुख्य और कभी-कभी इसका इस्तेमाल "डेटा स्टोर करने की जगह" के समानार्थी के रूप में भी किया जाता है.

डेटा स्टोर करने की कैननिकल जगह का नाम

वह कैननिकल नाम जिससे रिपॉज़िटरी (डेटा स्टोर करने की जगह) दी जाती है. इसके संदर्भ में का इस्तेमाल किया है, तो हर रिपॉज़िटरी का एक कैननिकल नाम होता है. रेपो के अंदर टारगेट अगर लेबल, canonical_name के कैननिकल नाम का पता लगाता है, तो @@canonical_name//pac/kage:target (डबल @ पर ध्यान दें).

डेटा स्टोर करने की मुख्य जगह में, कैननिकल नाम के तौर पर हमेशा खाली स्ट्रिंग होती है.

डेटा स्टोर करने की आसान जगह का नाम

वह नाम जहां रिपॉज़िटरी का पता लगाया जा सकता है. हालांकि, इसका इस्तेमाल किसी अन्य डेटा स्टोर करने के लिए किया जाता है. इसे रेपो के "निकनेम" के तौर पर माना जा सकता है: यह कैननिकल नाम वाला रेपो होता है डेटा स्टोर करने की जगह के हिसाब से, michael का नाम mike हो सकता है alice, लेकिन डेटा स्टोर करने के संदर्भ में इसका नाम mickey हो सकता है bob. इस मामले में, michael में मौजूद टारगेट पर लेबल, कार्रवाई कर सकता है alice के लिए @mike//pac/kage:target (एक ही @ पर ध्यान दें).

इसके उलट, इसे डेटा स्टोर करने की जगह की मैपिंग के तौर पर समझा जा सकता है: हर रेपो "बेहतर रेपो नाम" से मैपिंग बनाए रखता है से लिंक कर दें.

डेटा स्टोर करने की जगह का नियम

रिपॉज़िटरी की परिभाषाओं के लिए स्कीमा, जो बेज़ल को किसी डेटा स्टोर करने की जगह. उदाहरण के लिए, यह "किसी खास यूआरएल से zip फ़ाइल वाला संग्रह डाउनलोड करें" हो सकता है और उसे एक्सट्रैक्ट कर सकता है", या "कोई खास Maven आर्टफ़ैक्ट फ़ेच करता है और उसे java_import टारगेट" या बस "लोकल डायरेक्ट्री को सिमलिंक करें". हर डेटा स्टोर करने की जगह तय किया गया हो.

लिखने के तरीके के बारे में ज़्यादा जानकारी के लिए, डेटा स्टोर करने की जगह के नियम देखें डेटा स्टोर करने की जगह के लिए खास नियम बनाएं.

अब तक के सबसे सामान्य रेपो नियम हैं http_archive, जिससे संग्रह डाउनलोड होता है को एक्सट्रैक्ट करता है और local_repository, जो जो पहले से Basel का डेटा स्टोर करने की जगह है.

डेटा स्टोर करने की जगह फ़ेच करना

लोकल डिस्क को सुरक्षित रखने के लिए, रेपो नियम के हिसाब से होना चाहिए. वर्कस्पेस में तय किए गए रिपो, लोकल डिस्क में उपलब्ध नहीं हैं इससे पहले कि वे फ़ेच किए जाएं.

आम तौर पर, बेज़ल रेपो को सिर्फ़ तब फ़ेच करता है, जब उसे रेपो से किसी चीज़ की ज़रूरत होती है, और रेपो को पहले ही फ़ेच नहीं किया गया है. अगर डेटा स्टोर करने की जगह पहले ही फ़ेच की जा चुकी है से पहले, बेज़ेल इसे केवल तब ही री-फ़ेच करता है, जब उसकी परिभाषा बदल गई हो.

किसी डेटा स्टोर करने की जगह के लिए प्री-फ़ेच शुरू करने के लिए, fetch कमांड का इस्तेमाल किया जा सकता है, या सभी ज़रूरी डेटा स्टोर करने की जगहों को टारगेट कर सकता है. यह क्षमता --nofetch विकल्प का इस्तेमाल करके, ऑफ़लाइन बिल्ड चालू करती है.

--fetch विकल्प का इस्तेमाल, नेटवर्क ऐक्सेस को मैनेज करने के लिए किया जाता है. इसकी डिफ़ॉल्ट वैल्यू 'सही' होती है. हालांकि, गलत (--nofetch) पर सेट होने पर, निर्देश किसी भी कैश मेमोरी में सेव किए गए डेटा का इस्तेमाल करेगा निर्भरता का एक वर्शन है और अगर कोई भी मौजूद नहीं है, तो आदेश से अपलोड नहीं किया जा सका.

ज़्यादा जानकारी के लिए फ़ेच करने के विकल्प देखें फ़ेच कंट्रोल करने के बारे में जानकारी.

डायरेक्ट्री का लेआउट

फ़ेच किए जाने के बाद, रेपो को यहां दी गई सबडायरेक्ट्री external में देखा जा सकता है: आउटपुट बेस, अपने कैननिकल नाम के नीचे मौजूद है.

इस कमांड का इस्तेमाल करके, रेपो कॉन्टेंट को देखने के लिए इस कमांड का इस्तेमाल किया जा सकता है. कैननिकल नाम canonical_name:

ls $(bazel info output_base)/external/ canonical_name

REPO.baकोई फ़ाइल

REPO.bazel फ़ाइल का इस्तेमाल, डायरेक्ट्री ट्री की सबसे ऊपरी सीमा को मार्क करने के लिए किया जाता है जो डेटा स्टोर करता है. इसमें रेपो के रूप में काम करने के लिए कुछ भी शामिल करने की ज़रूरत नहीं है सीमा फ़ाइल; हालांकि, इसका इस्तेमाल कुछ सामान्य एट्रिब्यूट की जानकारी देने के लिए भी किया जा सकता है रिपो के अंदर सभी बिल्ड टारगेट के लिए तैयार किया जाता है.

REPO.bazel फ़ाइल का सिंटैक्स BUILD फ़ाइलों जैसा होता है. हालांकि, ऐसा नहीं है कि load स्टेटमेंट इस्तेमाल किए जा सकते हैं और सिर्फ़ एक फ़ंक्शन, repo() है उपलब्ध हैं. repo() वही तर्क लेता है जो package() में होते हैं BUILD फ़ाइलों में फ़ंक्शन; जबकि package() पैकेज में मौजूद सभी बिल्ड टारगेट के लिए सामान्य एट्रिब्यूट तय करता है, repo() समान रूप से यह, रेपो के अंदर सभी बिल्ड टारगेट के लिए करता है.

उदाहरण के लिए, डेटा स्टोर करने की जगह में मौजूद सभी टारगेट के लिए एक जैसा लाइसेंस तय किया जा सकता है. इसके लिए जिनके पास ये REPO.bazel फ़ाइल है:

repo(
    default_package_metadata = ["//:my_license"],
)

Bzlmod की मदद से बाहरी डिपेंडेंसी मैनेज करें

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

Basel मॉड्यूल एक Baज़र प्रोजेक्ट है, जिसमें एक से ज़्यादा प्लैटफ़ॉर्म हो सकते हैं जिसमें से हर एक वर्शन पर अलग-अलग मॉड्यूल के बारे में मेटाडेटा पब्लिश किया जाता है चालू करें. मॉड्यूल के रेपो रूट में, एक 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")

मॉड्यूल में सिर्फ़ अपनी डायरेक्ट डिपेंडेंसी होनी चाहिए, जो Bzlmod किसी Baze रजिस्ट्री — डिफ़ॉल्ट रूप से, Bagel Central रजिस्ट्री. रजिस्ट्री, डिपेंडेंसी' MODULE.bazel फ़ाइलें, जो बेज़ेल को पूरी जानकारी खोजने की अनुमति देती हैं वर्शन रिज़ॉल्यूशन करने से पहले, ट्रांज़िटिव डिपेंडेंसी ग्राफ़.

वर्शन रिज़ॉल्यूशन के बाद, जिसमें हर मॉड्यूल के लिए एक वर्शन चुना जाता है, बेज़ल, रजिस्ट्री से दोबारा सलाह लेते हैं और हर मॉड्यूल के लिए एक रेपो तय करने का तरीका बताते हैं (ज़्यादातर मामलों में, http_archive का इस्तेमाल करके).

मॉड्यूल डेटा के ऐसे हिस्से भी तय कर सकते हैं जिन्हें टैग कहा जाता है, जो मॉड्यूल रिज़ॉल्यूशन के बाद, मॉड्यूल एक्सटेंशन का इस्तेमाल किया जाता है का इस्तेमाल करें. इन एक्सटेंशन में, रेपो जैसी सुविधाएं हैं इससे उन्हें फ़ाइल I/O और नेटवर्क भेजने जैसी कार्रवाइयां करने में मदद मिलेगी अनुरोध. दूसरी चीज़ों के साथ-साथ, इनकी मदद से Basel को दूसरे पैकेज से इंटरैक्ट करने की सुविधा भी मिलती है मैनेजमेंट सिस्टम भी शामिल हैं और बेज़ल से बने डिपेंडेंसी ग्राफ़ के हिसाब से भी ऐसा करते हैं मॉड्यूल देखें.

WORKSPACE की मदद से डेटा स्टोर करने की जगह तय करें

अब तक, बाहरी डिपेंडेंसी को मैनेज किया जा सकता है. इसके लिए, WORKSPACE (या WORKSPACE.bazel) फ़ाइल. इस फ़ाइल का सिंटैक्स इससे मिलता-जुलता है BUILD फ़ाइलें, बिल्ड रूल के बजाय रेपो नियमों का इस्तेमाल कर रही हैं.

निम्न स्निपेट http_archive रेपो नियम का उपयोग करने के लिए WORKSPACE फ़ाइल:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "foo",
    urls = ["https://example.com/foo.zip"],
    sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)

स्निपेट, ऐसे रेपो के बारे में बताता है जिसका कैननिकल नाम foo है. WORKSPACE में सिस्टम में, डिफ़ॉल्ट रूप से, रेपो का कैननिकल नाम ही उसका साफ़ नाम होता है अन्य डेटा स्टोर करने की जगह.

यहां उपलब्ध फ़ंक्शन की पूरी सूची देखें WORKSPACE फ़ाइलें.

WORKSPACE सिस्टम की कमियां

जब से WORKSPACE सिस्टम बनाया गया था, तब से लेकर अब तक, उपयोगकर्ताओं ने इसमें ये शामिल हैं:

  • Basel किसी भी डिपेंडेंसी की WORKSPACE फ़ाइलों का आकलन नहीं करता है, इसलिए सभी ट्रांज़िटिव डिपेंडेंसी को मुख्यWORKSPACE repo का इस्तेमाल कर सकते हैं.
  • इस पर काम करने के लिए, प्रोजेक्ट ने "deps.bzl" को अपनाया है पैटर्न, जिसमें वे एक मैक्रो निर्धारित करते हैं, जो बदले में कई डेटा संग्रह स्थान को परिभाषित करता है और उपयोगकर्ताओं को इस मैक्रो को अपनी WORKSPACE फ़ाइलों में कॉल करें.
    • इसमें अपनी समस्याएं हैं: मैक्रो अन्य .bzl फ़ाइलों को load नहीं कर सकता, इसलिए इन प्रोजेक्ट को अपनी ट्रांज़िटिव डिपेंडेंसी को इस तरह तय करना होगा कि "डेप" का इस्तेमाल करें या उपयोगकर्ता से एक से ज़्यादा कॉल करके इस समस्या को हल करने का तरीका जानें लेयर वाला "deps" मैक्रो.
    • Baज़र, WORKSPACE फ़ाइल का क्रम से आकलन करता है. इसके अलावा, डिपेंडेंसी http_archive का इस्तेमाल करके, यूआरएल के साथ तय की जाती हैं. इसमें कोई वर्शन की जानकारी देखें. इसका मतलब है कि आपके पास ऐसा कोई भरोसेमंद तरीका नहीं है डायमंड डिपेंडेंसी के मामले में वर्शन रिज़ॉल्यूशन (A इस पर निर्भर करता है कि B और C; B और C, दोनों D के अलग-अलग वर्शन पर निर्भर करते हैं).

WorkSPACE की कमियों की वजह से, Bzlmod लेगसी की जगह ले रहा है आने वाले समय में Basel की रिलीज़ में वर्कस्पेस सिस्टम को शामिल किया जाएगा. कृपया Bzlmod माइग्रेशन पढ़ें गाइड में बताया गया है कि Bzlmod पर कैसे माइग्रेट करें.