इसकी कमियों के कारण WorkSPACE, Bzlmod प्रोसेस होने वाला है आने वाले समय में Basel की रिलीज़ में, लेगसी Workspace सिस्टम को बदलें. इस गाइड से आपको मदद मिलेगी तो आप अपने प्रोजेक्ट को Bzlmod पर माइग्रेट कर दें और बाहरी सोर्स फ़ेच करने के लिए वर्कस्पेस को छोड़ दें निर्भरता.
वर्कस्पेस बनाम Bzlmod
Basel के workspace और Bzlmod पर अलग-अलग सिंटैक्स के साथ मिलती-जुलती सुविधाएं होती हैं. यह सेक्शन में बताया गया है कि Workspace की कुछ सुविधाओं से, Bzlmod.
बेज़ल वर्कस्पेस का रूट तय करना
Workspace फ़ाइल बेज़ल प्रोजेक्ट के सोर्स रूट के तौर पर मार्क होती है, यह ज़िम्मेदारी
Baज़र के वर्शन 6.3 और उसके बाद के वर्शन में, MODULE.bagel से बदल गया है. Basel वर्शन के साथ
6.3 से पहले, WORKSPACE
या WORKSPACE.bazel
फ़ाइल में अभी भी
आपके फ़ाइल फ़ोल्डर का रूट देख सकते हैं. ऐसा इन टिप्पणियों के साथ किया जा सकता है:
वर्कस्पेस
# This file marks the root of the Bazel workspace. # See MODULE.bazel for external dependencies setup.
अपने batzlrc में Bzlmod मोड चालू करें
.bazelrc
आपको ऐसे फ़्लैग सेट करने देता है जो आपके Basel को चलाते समय हर बार लागू होते हैं. चालू करने के लिए
Bzlmod का, --enable_bzlmod
फ़्लैग का इस्तेमाल करके उसे common
कमांड पर लागू करें, ताकि
यह हर निर्देश पर लागू होता है:
.bazelrc
# Enable Bzlmod for every Bazel command common --enable_bzlmod
अपने फ़ाइल फ़ोल्डर के लिए रिपॉज़िटरी का नाम बताएं
वर्कस्पेस
workspace
फ़ंक्शन का इस्तेमाल किया जाता है का इस्तेमाल करें. इसकी मदद से,//foo:bar
को फ़ाइल फ़ोल्डर में@<workspace name>//foo:bar
के तौर पर रेफ़र करना होगा. अगर यह तय नहीं किया गया है, तो आपके डेटा स्टोर करने की डिफ़ॉल्ट जगह का नाम फ़ाइल फ़ोल्डर__main__
है.## WORKSPACE workspace(name = "com_foo_bar")
Bzlmod
हमारा सुझाव है कि आप एक ही फ़ाइल फ़ोल्डर में
@<repo name>
के बिना//foo:bar
सिंटैक्स. हालांकि, अगर आपको पुराने सिंटैक्स की ज़रूरत है , तो आप डेटा स्टोर करने की जगह के तौर परmodule
फ़ंक्शन नाम. अगर मॉड्यूल का नाम, डेटा स्टोर करने की ज़रूरी जगह के नाम से अलग है, तो आपकोrepo_name
एट्रिब्यूट का इस्तेमाल कर सकता हैmodule
फ़ंक्शन को ओवरराइड करने के लिए रिपॉज़िटरी का नाम.## MODULE.bazel module( name = "bar", repo_name = "com_foo_bar", )
बाहरी डिपेंडेंसी को Baज़र मॉड्यूल के तौर पर फ़ेच करें
अगर आपकी डिपेंडेंसी Basel प्रोजेक्ट है, तो आपको इस पर Basel मॉड्यूल, जब यह Bzlmod का भी इस्तेमाल करता है.
वर्कस्पेस
Workspace के साथ, आम तौर पर
http_archive
याgit_repository
डेटा स्टोर करने की जगह के नियमों को Basel प्रोजेक्ट के सोर्स डाउनलोड करने होंगे.## WORKSPACE load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "bazel_skylib", urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"], sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa", ) load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace") bazel_skylib_workspace() http_archive( name = "rules_java", urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"], sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a", ) load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains") rules_java_dependencies() rules_java_toolchains()
जैसा कि आपको दिख रहा है, यह एक ऐसा सामान्य पैटर्न है जिसका इस्तेमाल करके, उपयोगकर्ताओं को ट्रांज़िटिव लोड करना पड़ता है डिपेंडेंसी के मैक्रो से डिपेंडेंसी.
bazel_skylib
और, दोनों को मान लेंrules_java
,platform
पर निर्भर करता है,platform
के सटीक वर्शन निर्भरता मैक्रो के क्रम से तय होती है.Bzlmod
Bzlmod के साथ, जब तक आपकी डिपेंडेंसी Baez Central में उपलब्ध है) Registry या आपका कस्टम Bazu रजिस्ट्री की मदद से, आप आसानी से इस पर निर्भर
bazel_dep
डायरेक्टिव.## MODULE.bazel bazel_dep(name = "bazel_skylib", version = "1.4.2") bazel_dep(name = "rules_java", version = "6.1.1")
Bzlmod मॉड्यूल का इस्तेमाल करके, बैचल मॉड्यूल डिपेंडेंसी को चुटकियों में हल करता है: MVS एल्गोरिदम. इसलिए, अधिकतम
platform
का ज़रूरी वर्शन अपने-आप चुन लिया जाता है.
किसी डिपेंडेंसी को Basel मॉड्यूल के तौर पर बदलना
रूट मॉड्यूल के तौर पर, बेज़ल मॉड्यूल डिपेंडेंसी को अलग-अलग तरीके.
ज़्यादा जानकारी के लिए, कृपया ओवरराइड सेक्शन पढ़ें जानकारी.
इस्तेमाल के कुछ उदाहरण यहां दिए गए हैं: उदाहरण डेटा स्टोर करने की जगह.
मॉड्यूल एक्सटेंशन की मदद से बाहरी डिपेंडेंसी फ़ेच करें
अगर आपकी डिपेंडेंसी कोई Basel प्रोजेक्ट नहीं है या अभी तक किसी भी Basel में उपलब्ध नहीं है
रजिस्ट्री होती है, तो आप इसका उपयोग करके इसे प्रस्तुत कर सकते हैं
use_repo_rule
या मॉड्यूल
एक्सटेंशन.
वर्कस्पेस
http_file
का इस्तेमाल करके फ़ाइल डाउनलोड करें डेटा स्टोर करने की जगह का नियम है.## WORKSPACE load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") http_file( name = "data_file", url = "http://example.com/file", sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", )
Bzlmod
Bzlmod का इस्तेमाल करके, MODULE.batz का इस्तेमाल करके
use_repo_rule
डायरेक्टिव इस्तेमाल किया जा सकता है फ़ाइल को सीधे रेपोस को इंस्टैंशिएट करने के लिए इसका इस्तेमाल करें:## MODULE.bazel http_file = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") http_file( name = "data_file", url = "http://example.com/file", sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", )
हुड के तहत, इसे मॉड्यूल एक्सटेंशन का इस्तेमाल करके लागू किया जाता है. अगर आपको सिर्फ़ रेपो नियम लागू करने के बजाय, ज़्यादा जटिल लॉजिक लगाना है, मॉड्यूल एक्सटेंशन खुद लागू करें. आपको परिभाषा को दूसरी जगह ले जाना होगा एक
.bzl
फ़ाइल में जोड़ें, जो आपको इनके बीच की परिभाषा शेयर करने देता है डेटा दूसरी जगह भेजने की अवधि के दौरान, workspace और Bzlmod टूल का इस्तेमाल करें.## repositories.bzl load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") def my_data_dependency(): http_file( name = "data_file", url = "http://example.com/file", sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", )
डिपेंडेंसी मैक्रो लोड करने के लिए, एक मॉड्यूल एक्सटेंशन लागू करें. आप उसे मैक्रो की उसी
.bzl
फ़ाइल में रखना चाहिए, लेकिन उसके साथ काम करना जारी रखता है के पुराने वर्शन के लिए, इसे एक अलग.bzl
फ़ाइल में परिभाषित करना बेहतर होगा.## extensions.bzl load("//:repositories.bzl", "my_data_dependency") def _non_module_dependencies_impl(_ctx): my_data_dependency() non_module_dependencies = module_extension( implementation = _non_module_dependencies_impl, )
डेटा स्टोर करने की जगह को रूट प्रोजेक्ट में दिखाने के लिए, आपको मॉड्यूल एक्सटेंशन और MODULE.bagel फ़ाइल में रिपॉज़िटरी का इस्तेमाल.
## MODULE.bazel non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies") use_repo(non_module_dependencies, "data_file")
मॉड्यूल एक्सटेंशन की मदद से, बाहरी डिपेंडेंसी को हल करना
प्रोजेक्ट, एक ऐसा मैक्रो उपलब्ध करा सकता है जो डेटा की इनपुट देता है. लेकिन, अगर कॉल में एक से ज़्यादा कॉलर हैं, तो डिपेंडेंसी ग्राफ़ और उनसे समस्या पैदा होती है?
मान लें कि प्रोजेक्ट foo
यह मैक्रो देता है, जो version
को
एक तर्क दिया गया है.
## repositories.bzl in foo {:#repositories.bzl-foo}
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def data_deps(version = "1.0"):
http_file(
name = "data_file",
url = "http://example.com/file-%s" % version,
# Omitting the "sha256" attribute for simplicity
)
वर्कस्पेस
Workspace की मदद से,
@foo
से मैक्रो लोड किया जा सकता है और उसके लिए वर्शन तय किया जा सकता है पर निर्भर है. मान लें कि आपके पास कोई दूसरी डिपेंडेंसी@bar
है, यह@foo
पर भी निर्भर करता है. हालांकि, इसे डेटा के किसी दूसरे वर्शन की ज़रूरत होती है निर्भर है.## WORKSPACE # Introduce @foo and @bar. ... load("@foo//:repositories.bzl", "data_deps") data_deps(version = "2.0") load("@bar//:repositories.bzl", "bar_deps") bar_deps() # -> which calls data_deps(version = "3.0")
इस मामले में, अंतिम उपयोगकर्ता को मैक्रो के क्रम को उनकी ज़रूरत का वर्शन पाने के लिए वर्कस्पेस. यह सबसे बड़े दर्द में से एक है साथ ही, Workspace के पॉइंट भी शामिल करते हैं, क्योंकि यह प्रोसेस डिपेंडेंसी से जुड़ी समस्याओं को हल करें.
Bzlmod
Bzlmod के साथ,
foo
प्रोजेक्ट का लेखक विवाद. उदाहरण के लिए, मान लें कि हमेशा सभी Basel मॉड्यूल के लिए, डेटा डिपेंडेंसी का ज़्यादा से ज़्यादा वर्शन होना ज़रूरी है.## extensions.bzl in foo load("//:repositories.bzl", "data_deps") data = tag_class(attrs={"version": attr.string()}) def _data_deps_extension_impl(module_ctx): # Select the maximal required version in the dependency graph. version = "1.0" for mod in module_ctx.modules: for data in mod.tags.data: version = max(version, data.version) data_deps(version) data_deps_extension = module_extension( implementation = _data_deps_extension_impl, tag_classes = {"data": data}, )
## MODULE.bazel in bar bazel_dep(name = "foo", version = "1.0") foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension") foo_data_deps.data(version = "3.0") use_repo(foo_data_deps, "data_file")
## MODULE.bazel in root module bazel_dep(name = "foo", version = "1.0") bazel_dep(name = "bar", version = "1.0") foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension") foo_data_deps.data(version = "2.0") use_repo(foo_data_deps, "data_file")
इस मामले में, रूट मॉड्यूल को डेटा वर्शन
2.0
की ज़रूरत है, जबकि डिपेंडेंसीbar
के लिए3.0
की ज़रूरत है.foo
में मौजूद मॉड्यूल एक्सटेंशन, सही तरीके से काम कर सकता है इस समस्या का समाधान करें और डेटा के लिए अपने-आप वर्शन3.0
चुनें निर्भर है.
तीसरे पक्ष के पैकेज मैनेजर को जोड़ें
आखिरी सेक्शन के बाद देखें, क्योंकि मॉड्यूल एक्सटेंशन, Google Analytics 4 प्रॉपर्टी डिपेंडेंसी ग्राफ़ से मिली जानकारी. इस समस्या को हल करने के लिए, ज़रूरत के हिसाब से लॉजिक लागू करें डिपेंडेंसी और कॉल रिपॉज़िटरी के नियम लागू करने के लिए, ताकि एक्सटर्नल रिपॉज़िटरी शुरू की जा सके. इससे नियम बनाने वाले लेखक, नियमों के सेट को बेहतर बना पाते हैं खास भाषाओं के पैकेज मैनेजर.
ज़्यादा जानने के लिए, कृपया मॉड्यूल एक्सटेंशन पेज पढ़ें मॉड्यूल एक्सटेंशन इस्तेमाल करने के तरीके के बारे में जानकारी.
यहां उन नियमों की सूची दी गई है जो डिपेंडेंसी पाने के लिए Bzlmod का पहले से इस्तेमाल कर रहे हैं अलग-अलग पैकेज मैनेजर से मिले:
सूडो पैकेज मैनेजर को इंटिग्रेट करने वाला छोटा सा उदाहरण, उदाहरण डेटा स्टोर करने की जगह.
होस्ट मशीन पर टूलचेन का पता लगाएं
जब Basel के बिल्ड नियमों को यह पता लगाने की ज़रूरत हो कि आपके होस्ट पर कौनसे टूलचेन उपलब्ध हैं मशीन में, वे रिपॉज़िटरी के नियमों का इस्तेमाल करके होस्ट मशीन की जांच करते हैं और डेटा स्टोर करने की बाहरी जगहों के तौर पर टूलचेन की जानकारी.
वर्कस्पेस
शेल टूलचेन का पता लगाने के लिए, डेटा स्टोर करने की जगह का यह नियम दिया गया है.
## local_config_sh.bzl def _sh_config_rule_impl(repository_ctx): sh_path = get_sh_path_from_env("SH_BIN_PATH") if not sh_path: sh_path = detect_sh_from_path() if not sh_path: sh_path = "/shell/binary/not/found" repository_ctx.file("BUILD", """ load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain") sh_toolchain( name = "local_sh", path = "{sh_path}", visibility = ["//visibility:public"], ) toolchain( name = "local_sh_toolchain", toolchain = ":local_sh", toolchain_type = "@bazel_tools//tools/sh:toolchain_type", ) """.format(sh_path = sh_path)) sh_config_rule = repository_rule( environ = ["SH_BIN_PATH"], local = True, implementation = _sh_config_rule_impl, )
डेटा स्टोर करने की जगह के नियम को वर्कस्पेस में लोड किया जा सकता है.
## WORKSPACE load("//:local_config_sh.bzl", "sh_config_rule") sh_config_rule(name = "local_config_sh")
Bzlmod
Bzlmod की मदद से, एक ही डेटा स्टोर करने की जगह को मॉड्यूल एक्सटेंशन, यह पिछले समय में
@data_file
रिपॉज़िटरी को पेश करने जैसा ही है सेक्शन में जाएं.## local_config_sh_extension.bzl load("//:local_config_sh.bzl", "sh_config_rule") sh_config_extension = module_extension( implementation = lambda ctx: sh_config_rule(name = "local_config_sh"), )
फिर MODULE.batz फ़ाइल में एक्सटेंशन का उपयोग करें.
## MODULE.bazel sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension") use_repo(sh_config_ext, "local_config_sh")
टूलचेन रजिस्टर करें और प्रोग्राम चलाने के प्लैटफ़ॉर्म
रिपॉज़िटरी होस्ट करने वाले टूलचेन की शुरुआत करने के बाद, आखिरी सेक्शन में
जानकारी (जैसे local_config_sh
), तो आप शायद
टूलचेन.
वर्कस्पेस
Workspace का इस्तेमाल करके, टूलचेन को इन तरीकों से रजिस्टर किया जा सकता है.
आप टूलचेन
.bzl
फ़ाइल को रजिस्टर कर सकते हैं और मैक्रो को Workspace फ़ाइल.## local_config_sh.bzl def sh_configure(): sh_config_rule(name = "local_config_sh") native.register_toolchains("@local_config_sh//:local_sh_toolchain")
## WORKSPACE load("//:local_config_sh.bzl", "sh_configure") sh_configure()
या टूलचेन को सीधे Workspace फ़ाइल में रजिस्टर करें.
## WORKSPACE load("//:local_config_sh.bzl", "sh_config_rule") sh_config_rule(name = "local_config_sh") register_toolchains("@local_config_sh//:local_sh_toolchain")
Bzlmod
Bzlmod के साथ,
register_toolchains
औरregister_execution_platforms
एपीआई सिर्फ़ MODULE.baकोई फ़ाइल में उपलब्ध हैं. आपके पास कॉल करने की सुविधा नहीं हैnative.register_toolchains
को मॉड्यूल एक्सटेंशन में डालें.## MODULE.bazel sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension") use_repo(sh_config_ext, "local_config_sh") register_toolchains("@local_config_sh//:local_sh_toolchain")
WORKSPACE
में रजिस्टर किए गए टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म,
WORKSPACE.bzlmod
और हर Baze मॉड्यूल की MODULE.bazel
फ़ाइल इसका पालन करती है
टूलचेन चुनने के दौरान प्राथमिकता का क्रम (सबसे ज़्यादा से सबसे कम):
- रूट मॉड्यूल में रजिस्टर किए गए टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म
MODULE.bazel
फ़ाइल. WORKSPACE
में रजिस्टर किए गए टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म याWORKSPACE.bzlmod
फ़ाइल.- ऐसे मॉड्यूल के ज़रिए रजिस्टर किए गए टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म जो रूट मॉड्यूल की (ट्रांज़िव) डिपेंडेंसी.
WORKSPACE.bzlmod
का इस्तेमाल न करने पर:WORKSPACE
में रजिस्टर किए गए टूलचेन सफ़िक्स है.
डेटा स्टोर करने की स्थानीय जगहों के बारे में जानकारी देना
अगर आपको इसकी ज़रूरत हो, तो आपको लोकल रिपॉज़िटरी के तौर पर डिपेंडेंसी लागू करनी पड़ सकती है: डीबग करने के लिए डिपेंडेंसी का लोकल वर्शन या आप डायरेक्ट्री के तौर पर जोड़ा जा सकता है.
वर्कस्पेस
वर्कस्पेस इस्तेमाल करने पर, डेटा स्टोर करने के दो नेटिव नियमों का इस्तेमाल किया जाता है.
local_repository
औरnew_local_repository
.## WORKSPACE local_repository( name = "rules_java", path = "/Users/bazel_user/workspace/rules_java", )
Bzlmod
Bzlmod के साथ, यह इस्तेमाल किया जा सकता है
local_path_override
से लोकल पाथ वाले मॉड्यूल को बदलें.## MODULE.bazel bazel_dep(name = "rules_java") local_path_override( module_name = "rules_java", path = "/Users/bazel_user/workspace/rules_java", )
मॉड्यूल एक्सटेंशन के साथ, लोकल रिपॉज़िटरी की शुरुआत भी की जा सकती है. हालांकि, आप
native.local_repository
को मॉड्यूल एक्सटेंशन में कॉल नहीं कर सकते, डेटा स्टोर करने की जगह के सभी नियमों को बेहतर बनाने के लिए काम किया जा रहा है ( #18285 प्रोग्रेस के लिए). इसके बाद, किसी मॉड्यूल में संबंधित स्टारलार्कlocal_repository
को कॉल किया जा सकता है एक्सटेंशन चुनें. Search Ads 360 के नए वर्शन का इस्तेमाल करने पर, अगर यह ब्लॉक करने की समस्या है, तोlocal_repository
डेटा स्टोर करने की जगह का नियम सेट करें.
बाइंड टारगेट
Workspace में bind
नियम अब काम नहीं करता और
Bzlmod में समर्थित नहीं. यह सुविधा, टारगेट को एक उपनाम देने के लिए लॉन्च की गई थी
खास //external
पैकेज. इस तारीख के हिसाब से सभी उपयोगकर्ताओं को माइग्रेट कर दिया जाएगा.
उदाहरण के लिए, अगर आपके चैनल पर इतने सदस्य हैं
## WORKSPACE
bind(
name = "openssl",
actual = "@my-ssl//src:openssl-lib",
)
इससे दूसरे टारगेट, //external:openssl
पर निर्भर रहते हैं. आप माइग्रेट कर सकते हैं
इससे दूर रहें:
//external:openssl
के सभी इस्तेमाल को इससे बदलें@my-ssl//src:openssl-lib
.इसके अलावा,
alias
बिल्ड नियम का इस्तेमाल करेंपैकेज में इस टारगेट के बारे में बताएं (उदाहरण,
//third_party
)## third_party/BUILD alias( name = "openssl, actual = "@my-ssl//src:openssl-lib", )
//external:openssl
के सभी इस्तेमाल को इससे बदलें//third_party:openssl-lib
.
माइग्रेशन
यह सेक्शन, Bzlmod माइग्रेशन के लिए काम की जानकारी और दिशा-निर्देश देता है प्रोसेस.
वर्कस्पेस में अपनी डिपेंडेंसी के बारे में जानें
माइग्रेशन का पहला चरण यह समझना है कि आपके पास किस तरह की चीज़ें हैं. यह
यह पता लगाना मुश्किल हो सकता है कि
किस तरह की सटीक जानकारी
workspace फ़ाइल, क्योंकि ट्रांज़िटिव डिपेंडेंसी अक्सर *_deps
के साथ लोड होती हैं
मैक्रो.
फ़ाइल फ़ोल्डर में समाधान की गई फ़ाइल के साथ बाहरी डिपेंडेंसी की जांच करें
अच्छी बात यह है कि
--experimental_repository_resolved_file
मदद कर सकते हैं. यह फ़्लैग ज़रूरी है, एक "लॉक फ़ाइल" जनरेट करता है फ़ेच किए गए सभी बाहरी सोर्स का प्रतिशत
डिपेंडेंसी के तौर पर एक्सपोर्ट करें. ज़्यादा जानकारी के लिए, यह ब्लॉग पढ़ें
पोस्ट.
इसका इस्तेमाल दो तरीकों से किया जा सकता है:
कुछ खास टारगेट बनाने के लिए ज़रूरी बाहरी डिपेंडेंसी की जानकारी पाने के लिए.
bazel clean --expunge bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
वर्कस्पेस फ़ाइल में तय की गई सभी बाहरी डिपेंडेंसी की जानकारी फ़ेच करने के लिए.
bazel clean --expunge bazel sync --experimental_repository_resolved_file=resolved.bzl
bazel sync
कमांड का इस्तेमाल करके, Workspace फ़ाइल, जिसमें यह शामिल है:bind
का इस्तेमालregister_toolchains
औरregister_execution_platforms
का इस्तेमाल
हालांकि, अगर आपका प्रोजेक्ट क्रॉस प्लैटफ़ॉर्म पर है, तो हो सकता है कि सिंक की प्रोसेस रुक जाए क्योंकि कुछ रिपॉज़िटरी नियम सिर्फ़ उन ब्राउज़र पर ही सही तरीके से काम कर सकते हैं जिन पर प्लैटफ़ॉर्म.
आदेश चलाने के बाद, आपके पास अपने बाहरी
डिपेंडेंसी resolved.bzl
फ़ाइल में शामिल होनी चाहिए.
bazel query
की मदद से बाहरी डिपेंडेंसी की जांच करें
आपको यह भी पता होगा कि bazel query
का इस्तेमाल, डेटा स्टोर करने की जगह के नियमों की जांच करने के लिए किया जा सकता है
bazel query --output=build //external:<repo name>
यह ज़्यादा सुविधाजनक और तेज़ है, लेकिन बेज़ल क्वेरी बाहरी डिपेंडेंसी वर्शन, इसलिए, इसका इस्तेमाल सावधानी से करें! बाहरी सोर्स से क्वेरी करना और जांच करना Bzlmod के साथ डिपेंडेंसी नई सबमिट करें.
पहले से मौजूद डिफ़ॉल्ट डिपेंडेंसी
अगर --experimental_repository_resolved_file
से जनरेट की गई फ़ाइल को देखा जाता है, तो
आपको ऐसी कई डिपेंडेंसी मिलेंगी जो आपके वर्कस्पेस में तय नहीं की गई हैं.
ऐसा इसलिए है, क्योंकि Baज़र ने उपयोगकर्ता के Workspace में प्रीफ़िक्स और सफ़िक्स जोड़ दिए हैं
कुछ डिफ़ॉल्ट डिपेंडेंसी को इंजेक्ट करने के लिए फ़ाइल कॉन्टेंट की ज़रूरत होती है, जो आम तौर पर
नेटिव नियम (जैसे, @bazel_tools
, @platforms
, और @remote_java_tools
). के साथ
Bzlmod फ़ॉर्मैट में, ये डिपेंडेंसी बिल्ट-इन मॉड्यूल के साथ उपलब्ध कराई जाती हैं
bazel_tools
, जो सभी के लिए डिफ़ॉल्ट डिपेंडेंसी है
बेज़ल मॉड्यूल.
माइग्रेशन के लिए हाइब्रिड मोड
Bzlmod और वर्कस्पेस, दोनों साथ काम कर सकते हैं. इससे डिपेंडेंसी माइग्रेट करने की सुविधा मिलती है Workspace फ़ाइल से Bzlmod तक, धीरे-धीरे प्रोसेस होना चाहिए.
WORKSPACE.bzlmod
माइग्रेशन के दौरान, Basel का इस्तेमाल करने वालों को बिल्ड और बिल्ड के बीच स्विच करना पड़ सकता है बिना Bzlmod सक्षम किया हुआ है. आसान हो जाता है.
WorkSPACE.bzlmod का सिंटैक्स और WorkSPACE बिलकुल एक जैसा है. Bzlmod के चालू होने पर, अगर फ़ाइल फ़ोल्डर के रूट में WorkSPACE.bzlmod फ़ाइल भी मौजूद है, तो:
WORKSPACE.bzlmod
लागू होता है औरWORKSPACE
की सामग्री को अनदेखा कर दिया जाता है.- कोई प्रीफ़िक्स या सफ़िक्स नहीं है workspace.bzlmod फ़ाइल में जोड़ा गया.
WorkSPACE.bzlmod फ़ाइल का इस्तेमाल करके, माइग्रेशन को आसान बनाया जा सकता है, क्योंकि:
- Bzlmod के बंद होने पर, वापस से डिपेंडेंसी फ़ेच की जाती है मूल वर्कस्पेस फ़ाइल का इस्तेमाल किया जा सकता है.
- Bzlmod चालू होने पर, यह बेहतर तरीके से ट्रैक किया जा सकता है कि कौनसी डिपेंडेंसी बची है workspace.bzlmod के साथ माइग्रेट करें.
डेटा स्टोर करने की जगह की जानकारी देखने की सुविधा
Bzlmod यह कंट्रोल कर सकता है कि दिए गए डेटा में से कौनसे अन्य डेटा स्टोर करने की जगहें दिखें रिपॉज़िटरी, डेटा स्टोर करने की जगहों के नाम और सख्त डेप पर जाएं.
यहां अलग-अलग तरह के डेटा स्टोर करने की जगह पर दिखने वाले डेटा के बारे में खास जानकारी दी गई है डेटा स्टोर करने की जगहों को ध्यान में रखते हुए काम करती है.
मुख्य डेटा स्टोर करने की जगह से | Basel मॉड्यूल रिपोज़ से | मॉड्यूल एक्सटेंशन डेटा स्टोर से | Workspace डेटा स्टोर से | |
---|---|---|---|---|
डेटा स्टोर करने की मुख्य जगह | दिख रहा है | अगर रूट मॉड्यूल कोई डायरेक्ट डिपेंडेंसी है | अगर रूट मॉड्यूल, मॉड्यूल एक्सटेंशन को होस्ट करने वाले मॉड्यूल पर सीधे निर्भर है या नहीं | दिख रहा है |
बेज़ल मॉड्यूल रिपोज़ | सीधे तौर पर डायरेक्ट डिपार्टमेंट | सीधे तौर पर डायरेक्ट डिपार्टमेंट | मॉड्यूल एक्सटेंशन होस्ट करने वाले मॉड्यूल का सीधा डिपार्टमेंट | रूट मॉड्यूल का डायरेक्ट डेवलपमेंट |
मॉड्यूल एक्सटेंशन डेटा स्टोर करने की जगह | सीधे तौर पर डायरेक्ट डिपार्टमेंट | सीधे तौर पर डायरेक्ट डिपार्टमेंट | मॉड्यूल एक्सटेंशन होस्ट करने वाले मॉड्यूल का डायरेक्ट डिपार्टमेंट और एक ही मॉड्यूल एक्सटेंशन से जनरेट होने वाले सभी डेटा संग्रह | रूट मॉड्यूल का डायरेक्ट डेवलपमेंट |
Workspace डेटा स्टोर करने की जगह | सभी दिख रहे हैं | नहीं दिख रहा है | नहीं दिख रहा है | सभी दिख रहे हैं |
माइग्रेट करने का तरीका
एक सामान्य Bzlmod माइग्रेशन प्रोसेस इस तरह दिख सकती है:
- Workspace में अपनी डिपेंडेंसी के बारे में जानें.
- अपने प्रोजेक्ट रूट में कोई खाली MODULE.baकोई फ़ाइल जोड़ें.
- Workspace फ़ाइल का कॉन्टेंट बदलने के लिए, खाली workspace.bzlmod फ़ाइल जोड़ें.
- Bzlmod चालू करके टारगेट बनाएं और देखें कि कौनसा रिपॉज़िटरी है मौजूद नहीं हैं.
- रिज़ॉल्व की गई डिपेंडेंसी में मौजूद डेटा स्टोर करने की जगह की परिभाषा देखना फ़ाइल से लिए जाते हैं.
- किसी मॉड्यूल की मदद से, छूटी हुई डिपेंडेंसी को Basel मॉड्यूल के तौर पर पेश करना एक्सटेंशन का भी इस्तेमाल किया जा सकता है या बाद में माइग्रेशन के लिए, इसे workspace.bzlmod में छोड़ दें.
- चार पर वापस जाएं और सभी डिपेंडेंसी उपलब्ध होने तक दोहराएं.
माइग्रेशन टूल
एक इंटरैक्टिव Bzlmod माइग्रेशन हेल्पर स्क्रिप्ट है जो में आपकी मदद कैसे की जा सकती है.
स्क्रिप्ट ये काम करती है:
- वर्कस्पेस में हल की गई फ़ाइल जनरेट करें और उसे पार्स करें.
- रिज़ॉल्व की गई फ़ाइल में मौजूद डेटा स्टोर करने की जगह की जानकारी को इस तरह से प्रिंट करें कि उसे आसानी से पढ़ा जा सके.
- बेज़ल बिल्ड कमांड चलाएं, गड़बड़ी के पहचाने गए मैसेज का पता लगाएं, और का नया तरीका इस्तेमाल करना चाहिए.
- देखें कि बीसीआर में पहले से कोई डिपेंडेंसी उपलब्ध है या नहीं.
- MODULE.basel फ़ाइल पर डिपेंडेंसी जोड़ें.
- मॉड्यूल एक्सटेंशन की मदद से, डिपेंडेंसी जोड़ें.
- WorkSPACE.bzlmod फ़ाइल पर डिपेंडेंसी जोड़ें.
इसका इस्तेमाल करने के लिए, पक्का करें कि आपके पास Baज़र की नई रिलीज़ इंस्टॉल की गई हो और निम्न आदेश:
git clone https://github.com/bazelbuild/bazel-central-registry.git
cd <your workspace root>
<BCR repo root>/tools/migrate_to_bzlmod.py -t <your build targets>
Baज़र के मॉड्यूल पब्लिश करें
अगर आपका Basel प्रोजेक्ट दूसरे प्रोजेक्ट पर निर्भर है, तो अपनी प्रोजेक्ट करने के लिए सबमिट किए गए हैं.
बीसीआर में अपने प्रोजेक्ट की जांच करने के लिए, आपके पास को भी शामिल किया है. सोर्स संग्रह बनाते समय कुछ बातों का ध्यान रखें:
पक्का करें कि संग्रह किसी खास वर्शन पर ले जाता हो.
BCR सिर्फ़ वर्शन वाले सोर्स संग्रह स्वीकार कर सकता है, क्योंकि Bzlmod को डिपेंडेंसी रिज़ॉल्यूशन के दौरान वर्शन की तुलना करें.
पक्का करें कि संग्रह का यूआरएल बिना किसी बदलाव के काम करता हो.
Basel, संग्रह के कॉन्टेंट की पुष्टि एक हैश वैल्यू के ज़रिए करता है. इसलिए, आपको यह पक्का कर लें कि डाउनलोड की गई फ़ाइल का चेकसम कभी न बदलता हो. अगर यूआरएल GitHub से, कृपया एक रिलीज़ संग्रह बनाएं और रिलीज़ पेज में उसे अपलोड करें. GitHub इस बात की गारंटी नहीं देता है कि मांग. कम शब्दों में कहें, तो यूआरएल
https://github.com/<org>/<repo>/releases/download/...
को स्थिर माना जाता है जबकिhttps://github.com/<org>/<repo>/archive/...
नहीं है. GitHub देखें चेकसम संग्रहित करें कुछ समय के लिए उपलब्ध नहीं होना हमारा वीडियो देखें.पक्का करें कि सोर्स ट्री, ओरिजनल रिपॉज़िटरी के लेआउट के मुताबिक हो.
अगर आपका रिपॉज़िटरी बहुत बड़ा है और आपको डिस्ट्रिब्यूशन बनाना है गैर-ज़रूरी सोर्स को हटाकर, कम साइज़ के साथ संग्रहित करें, कृपया पक्का करें कि स्ट्रिप किया गया सोर्स ट्री, ओरिजनल सोर्स ट्री का सबसेट हो. यह असली उपयोगकर्ताओं के लिए, मॉड्यूल को रिलीज़ न होने वाले वर्शन में बदलना आसान हो जाता है
archive_override
का वर्शन औरgit_override
.किसी ऐसी सबडायरेक्ट्री में टेस्ट मॉड्यूल शामिल करें जो आपके सबसे आम एपीआई.
एक टेस्ट मॉड्यूल बेज़ल प्रोजेक्ट है, जिसका अपना वर्कस्पेस और MODULE.bazu है यह स्रोत संग्रह की सबडायरेक्ट्री में मौजूद होती है, जो मॉड्यूल का इस्तेमाल करें. इसमें उदाहरण के तौर पर या कुछ इंटिग्रेशन की जांच करें. इसमें आपके सबसे सामान्य एपीआई को कवर किया जाता है. इस्तेमाल की जानकारी test मॉड्यूल को देखें और इसे सेट अप करने का तरीका जानें.
जब आपके पास अपने सोर्स का संग्रह का यूआरएल तैयार हो, तो बीसीआर योगदान को अपनाएं GitHub की मदद से, बीसीआर को अपना मॉड्यूल सबमिट करने के लिए दिशा-निर्देश पुल का अनुरोध.
हमारा सुझाव है कि आपपर सेट अप करने के बाद BCR GitHub ऐप्लिकेशन पर डेटा स्टोर करने की जगह का इस्तेमाल करेगा. यह बीसीआर में आपके मॉड्यूल को सबमिट करने की प्रोसेस को ऑटोमेट करता है.
सबसे सही तरीके
इस सेक्शन में कुछ सबसे सही तरीके बताए गए हैं, जिनका पालन आपको बेहतर ढंग से करने के लिए करना चाहिए बाहरी डिपेंडेंसी मैनेज करना.
गै़र-ज़रूरी डिपेंडेंसी पाने से बचने के लिए, टारगेट को अलग-अलग पैकेज में बांटें.
#12835 देखें, जहां डेवलपर इसलिए, टेस्ट की डिपेंडेंसी को बिना वजह, जिन्हें उनकी ज़रूरत नहीं है. यह Bzlmod खास नहीं है, लेकिन इन तरीकों से डेवलपर डिपेंडेंसी को सही तरीके से तय करना आसान हो जाता है.
डेवलपर डिपेंडेंसी के बारे में बताएं
dev_dependency
एट्रिब्यूट को 'सही है' पर सेट किया जा सकता है
bazel_dep
और
use_extension
डायरेक्टिव, ताकि
ये डिपेंडेंट प्रोजेक्ट पर लागू नहीं होते. रूट मॉड्यूल के रूप में, आप
--ignore_dev_dependency
फ़्लैग करके पुष्टि करें कि आपके टारगेट
इनमें डेवलपर डिपेंडेंसी के बिना भी बनाया जाता है.
समुदाय के डेटा को दूसरी जगह भेजने की प्रक्रिया
आप यह जानकारी पाने के लिए Bazu Central Registry पर जा सकते हैं हटाएं. आप चाहें, तो इसमें शामिल हो जाएं इसके लिए, GitHub पर चर्चा उन डिपेंडेंसी को पसंद या पोस्ट करें जो आपके माइग्रेशन को रोक रही हैं.
समस्याओं की शिकायत करना
जानी-पहचानी Bzlmod के लिए, कृपया Bagel GitHub की समस्या की सूची देखें समस्याएं. अनब्लॉक करने में मदद पाने के लिए, नई समस्याएं या सुविधा के अनुरोध करें आपका माइग्रेशन!