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 को दूसरे पैकेज से इंटरैक्ट करने की सुविधा भी मिलती है मैनेजमेंट सिस्टम भी शामिल हैं और बेज़ल से बने डिपेंडेंसी ग्राफ़ के हिसाब से भी ऐसा करते हैं मॉड्यूल देखें.
Bzlmod पर बाहरी लिंक
- baज़लbuild/उदाहरण में Bzlmod इस्तेमाल के उदाहरण
- बेज़ल एक्सटर्नल डिपेंडेंसी ओवरहॉल (ओरिजनल Bzlmod डिज़ाइन दस्तावेज़)
- BzlCon 2021 प्रोग्राम के दौरान, Bzlmod चैनल पर हुई बातचीत
- Bzlmod चैनल पर, बैजल कम्यूनिटी डे पर चर्चा
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 पर कैसे माइग्रेट करें.