BaselCon 2024 का रजिस्ट्रेशन अब शुरू हो गया है!

इस पेज का अनुवाद Cloud Translation API से किया गया है.

Bzlmod माइग्रेशन गाइड

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

इसकी कमियों के कारण 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 का इस्तेमाल करके, टूलचेन को इन तरीकों से रजिस्टर किया जा सकता है.
1. आप टूलचेन .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()
```
2. या टूलचेन को सीधे 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",
)
```
ध्यान दें: local_path_override के साथ, आप सिर्फ़ लोकल डायरेक्ट्री जोड़ सकते हैं का मतलब है कि इसमें एक MODULE.basel फ़ाइल होनी चाहिए और डिपेंडेंसी के दौरान ट्रांज़िटिव डिपेंडेंसी को ध्यान में रखा जाता है का रिज़ॉल्यूशन. इसके अलावा, सभी मॉड्यूल ओवरराइड डायरेक्टिव का इस्तेमाल सिर्फ़ यहां किया जा सकता है रूट मॉड्यूल में इस्तेमाल किया जा सकता है.

मॉड्यूल एक्सटेंशन के साथ, लोकल रिपॉज़िटरी की शुरुआत भी की जा सकती है. हालांकि, आप 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 की समस्या की सूची देखें समस्याएं. अनब्लॉक करने में मदद पाने के लिए, नई समस्याएं या सुविधा के अनुरोध करें आपका माइग्रेशन!

Bzlmod माइग्रेशन गाइड

वर्कस्पेस बनाम Bzlmod

बेज़ल वर्कस्पेस का रूट तय करना

अपने batzlrc में Bzlmod मोड चालू करें

अपने फ़ाइल फ़ोल्डर के लिए रिपॉज़िटरी का नाम बताएं

बाहरी डिपेंडेंसी को Baज़र मॉड्यूल के तौर पर फ़ेच करें

किसी डिपेंडेंसी को Basel मॉड्यूल के तौर पर बदलना

मॉड्यूल एक्सटेंशन की मदद से बाहरी डिपेंडेंसी फ़ेच करें

मॉड्यूल एक्सटेंशन की मदद से, बाहरी डिपेंडेंसी को हल करना

तीसरे पक्ष के पैकेज मैनेजर को जोड़ें

होस्ट मशीन पर टूलचेन का पता लगाएं

टूलचेन रजिस्टर करें और प्रोग्राम चलाने के प्लैटफ़ॉर्म

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

बाइंड टारगेट

माइग्रेशन

वर्कस्पेस में अपनी डिपेंडेंसी के बारे में जानें

फ़ाइल फ़ोल्डर में समाधान की गई फ़ाइल के साथ बाहरी डिपेंडेंसी की जांच करें

bazel query की मदद से बाहरी डिपेंडेंसी की जांच करें

पहले से मौजूद डिफ़ॉल्ट डिपेंडेंसी

माइग्रेशन के लिए हाइब्रिड मोड

WORKSPACE.bzlmod

डेटा स्टोर करने की जगह की जानकारी देखने की सुविधा

माइग्रेट करने का तरीका

माइग्रेशन टूल

Baज़र के मॉड्यूल पब्लिश करें

सबसे सही तरीके

गै़र-ज़रूरी डिपेंडेंसी पाने से बचने के लिए, टारगेट को अलग-अलग पैकेज में बांटें.

डेवलपर डिपेंडेंसी के बारे में बताएं

समुदाय के डेटा को दूसरी जगह भेजने की प्रक्रिया

समस्याओं की शिकायत करना

`bazel query` की मदद से बाहरी डिपेंडेंसी की जांच करें