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

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

Workspace की कमियों की वजह से Bzlmod, Bazel की आने वाली रिलीज़ में लेगसी Workspace सिस्टम की जगह ले रहा है. इस गाइड से आपको अपने प्रोजेक्ट को Bzlmod में माइग्रेट करने और बाहरी डिपेंडेंसी फ़ेच करने के लिए, Workspace को छोड़ने में मदद मिलती है.

WORKSPACE बनाम Bzlmod

Bazel का Workspace और Bzlmod अलग-अलग सिंटैक्स में एक जैसी सुविधाएं देता है. इस सेक्शन में, Workspace की खास सुविधाओं से Bzlmod में माइग्रेट करने का तरीका बताया गया है.

Bazel वर्कस्पेस का रूट तय करना

WORKSPACE फ़ाइल, Bazel प्रोजेक्ट का सोर्स रूट है. Bazel के 6.3 और इसके बाद के वर्शन में, इस ज़िम्मेदारी को MODULE.bazel से बदल दिया गया है. Bazel वर्शन, 6.3 से पहले के वर्शन में, आपके वर्कस्पेस रूट में WORKSPACE या WORKSPACE.bazel फ़ाइल मौजूद होनी चाहिए, जैसे कि:

वर्कस्पेस

# This file marks the root of the Bazel workspace.
# See MODULE.bazel for external dependencies setup.

अपने bazelrc में Bzlmod चालू करें

.bazelrc आपको ऐसे फ़्लैग सेट करने की सुविधा देता है जो हर बार Bazel चलाने पर लागू होते हैं. 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 फ़ंक्शन से तय किए गए मॉड्यूल का नाम, डेटा स्टोर करने की जगह के नाम के तौर पर इस्तेमाल किया जा सकता है. अगर मॉड्यूल का नाम, ज़रूरी डेटा स्टोर करने की जगह के नाम से अलग है, तो रिपॉज़िटरी के नाम को बदलने के लिए, module फ़ंक्शन के repo_name एट्रिब्यूट का इस्तेमाल किया जा सकता है.
```
## MODULE.bazel
module(
    name = "bar",
    repo_name = "com_foo_bar",
)
```

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

अगर आपका डिपेंडेंसी, Bazel प्रोजेक्ट है, तो Bzlmod को अपनाने के बाद, आप Bezel मॉड्यूल के तौर पर इस पर निर्भर हो सकते हैं.

वर्कस्पेस

Workspace में, आम तौर पर http_archive या git_repository डेटा स्टोर करने की जगह के नियमों का इस्तेमाल किया जाता है. इससे, Bazel प्रोजेक्ट के सोर्स डाउनलोड किए जा सकते हैं.
```
## 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 के साथ, अगर आपकी डिपेंडेंसी Bazel Central Registry या आपकी कस्टम Bazel रजिस्ट्री में उपलब्ध है, तो आपको bazel_dep डायरेक्टिव की मदद से इस पर निर्भर रहना होगा.
```
## MODULE.bazel
bazel_dep(name = "bazel_skylib", version = "1.4.2")
bazel_dep(name = "rules_java", version = "6.1.1")
```
Bzlmod, MVS एल्गोरिदम का इस्तेमाल करके, Bazel मॉड्यूल डिपेंडेंसी के तौर पर फ़िलहाल काम करता है. इसलिए, platform का सबसे ज़्यादा ज़रूरी वर्शन अपने-आप चुन लिया जाता है.

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

रूट मॉड्यूल के तौर पर, Bazel मॉड्यूल डिपेंडेंसी को अलग-अलग तरीकों से बदला जा सकता है.

ज़्यादा जानकारी के लिए, कृपया ओवरराइड सेक्शन पढ़ें.

उदाहरण डेटा स्टोर करने की जगह में, इस्तेमाल के कुछ उदाहरण देखे जा सकते हैं.

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

अगर आपकी डिपेंडेंसी, Bazel प्रोजेक्ट नहीं है या अभी तक किसी Bazel रजिस्ट्री में उपलब्ध नहीं है, तो मॉड्यूल एक्सटेंशन का इस्तेमाल करके इसकी जानकारी दें.

वर्कस्पेस

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 में आपको परिभाषा को .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 फ़ाइल में तय किया जा सकता है, लेकिन Bazel के पुराने वर्शन के साथ काम करते रहने के लिए, इसे एक अलग .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.bazel फ़ाइल में, मॉड्यूल एक्सटेंशन और रिपॉज़िटरी के इस्तेमाल का एलान करना होगा.
```
## 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 में मैक्रो का क्रम ध्यान से बदलना होगा. यह Workspace की सबसे बड़ी मुश्किलों में से एक है, क्योंकि यह किसी भी तरह की समस्या को सही तरीके से हल नहीं करता.
Bzlmod

Bzlmod के साथ, प्रोजेक्ट foo का लेखक विवादों को सुलझाने के लिए मॉड्यूल एक्सटेंशन का इस्तेमाल कर सकता है. उदाहरण के लिए, मान लेते हैं कि सभी Bazel मॉड्यूल में से, डेटा डिपेंडेंसी के ज़्यादा से ज़्यादा ज़रूरी वर्शन को चुनना सही होगा.
```
## 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 वर्शन चुन सकता है.

तीसरे पक्ष के पैकेज मैनेजर को इंटिग्रेट करें

आखिरी सेक्शन के बाद, मॉड्यूल एक्सटेंशन डिपेंडेंसी ग्राफ़ से जानकारी इकट्ठा करने, डिपेंडेंसी के लिए कस्टम लॉजिक इस्तेमाल करने, बाहरी रिपॉज़िटरी लागू करने के लिए कॉल रिपॉज़िटरी के नियमों का इस्तेमाल करने का तरीका देता है. इससे, नियमों के लेखकों को खास भाषाओं के लिए पैकेज मैनेजर को इंटिग्रेट करने वाले नियमों के दायरे को बेहतर बनाने का बेहतरीन तरीका मिलता है.

मॉड्यूल एक्सटेंशन को इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, कृपया मॉड्यूल एक्सटेंशन पेज देखें.

यहां उन नियमों की सूची दी गई है जो अलग-अलग पैकेज मैनेजर से डिपेंडेंसी पाने के लिए, Bzlmod का पहले से इस्तेमाल कर रहे हैं:

examples डेटा स्टोर करने की जगह पर, सूडो पैकेज मैनेजर को इंटिग्रेट करने वाला एक छोटा-सा उदाहरण उपलब्ध है.

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

जब Bazel के बिल्ड नियमों को यह पता लगाना होता है कि आपकी होस्ट मशीन पर कौनसा टूलचेन उपलब्ध है, तो वे होस्ट मशीन की जांच करने और टूलचेन की जानकारी को बाहरी डेटा स्टोर करने की जगहों के तौर पर जनरेट करने के लिए, डेटा स्टोर करने की जगह के नियमों का इस्तेमाल करते हैं.

वर्कस्पेस

शेल टूलचेन का पता लगाने के लिए, डेटा स्टोर करने के इस नियम को ध्यान में रखते हुए.

## 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 में डेटा स्टोर करने की जगह के नियम को लोड किया जा सकता है.

## 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.bazel फ़ाइल में एक्सटेंशन का इस्तेमाल करें.
```
## 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 फ़ाइल में रजिस्टर करने और मैक्रो को वर्कस्पेस फ़ाइल में लोड करने का विकल्प है.
```
## 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.bazel फ़ाइल में उपलब्ध हैं. किसी मॉड्यूल एक्सटेंशन में 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 की मदद से, यह तय करने के लिए, डेटा स्टोर करने के दो नेटिव नियमों 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 के साथ, किसी लोकल डायरेक्ट्री को सिर्फ़ Bazel मॉड्यूल के तौर पर पेश किया जा सकता है. इसका मतलब है कि इसमें MODULE.bazel फ़ाइल होनी चाहिए. साथ ही, डिपेंडेंसी समस्या को हल करने के दौरान, इसकी ट्रांज़िशन डिपेंडेंसी को ध्यान में रखा जाता है. इसके अलावा, सभी मॉड्यूल ओवरराइड निर्देशों का इस्तेमाल सिर्फ़ रूट मॉड्यूल कर सकता है.

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

माइग्रेशन का पहला चरण यह समझना है कि आपके पास किन चीज़ों की निर्भरता है. इसलिए, यह पता लगाना मुश्किल हो सकता है कि Workspace फ़ाइल में कौनसी सटीक डिपेंडेंसी शामिल की गई हैं, क्योंकि ट्रांज़िटिव डिपेंडेंसी, अक्सर *_deps मैक्रो से लोड की जाती हैं.

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

अच्छी बात यह है कि फ़्लैग से आपको मदद मिल सकती है.--experimental_repository_resolved_file यह फ़्लैग आपकी आखिरी Bazel कमांड में, फ़ेच की गई सभी बाहरी डिपेंडेंसी की "लॉक फ़ाइल" जनरेट करता है. ज़्यादा जानकारी के लिए, यह ब्लॉग पोस्ट पढ़ें.

इसका इस्तेमाल दो तरह से किया जा सकता है:

कुछ खास टारगेट बनाने के लिए ज़रूरी बाहरी डिपेंडेंसी की जानकारी पाने के लिए.
```
bazel clean --expunge
bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
```
WORKSPACE फ़ाइल में दी गई सभी बाहरी डिपेंडेंसी की जानकारी फ़ेच करने के लिए.
```
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 से जनरेट की गई फ़ाइल देखी जाती है, तो आपको ऐसी कई डिपेंडेंसी दिखेंगी जो आपके वर्कस्पेस में तय नहीं हैं. ऐसा इसलिए है, क्योंकि Bazel कुछ डिफ़ॉल्ट डिपेंडेंसी शामिल करने के लिए, उपयोगकर्ता की WORKSPACE फ़ाइल के कॉन्टेंट में प्रीफ़िक्स और सफ़िक्स जोड़ता है. ये डिफ़ॉल्ट डिपेंडेंसी, आम तौर पर नेटिव नियमों (जैसे कि @bazel_tools, @platforms, और @remote_java_tools) के लिए ज़रूरी होते हैं. Bzlmod के साथ, ये डिपेंडेंसी, बिल्ट-इन मॉड्यूल bazel_tools के साथ पेश की जाती हैं, जो कि हर दूसरे Bazel मॉड्यूल के लिए डिफ़ॉल्ट डिपेंडेंसी है.

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

Bzlmod और WORKSPACE साथ-साथ काम कर सकते हैं. इससे, Workspace की डिपेंडेंसी को WORKSPACE फ़ाइल से Bzlmod में माइग्रेट करने की प्रोसेस धीमी हो जाती है.

Workspace.bzlmod

माइग्रेशन के दौरान, Bazel उपयोगकर्ताओं को Bzlmod चालू किए गए और इसके बिना बिल्ड के बीच स्विच करना पड़ सकता है. इस प्रोसेस को आसान बनाने के लिए, WORKSPACE.bzlmod सहायता लागू की गई है.

WORKSPACE.bzlmod का सिंटैक्स ठीक वही है जो WORKSPACE का है. Bzlmod चालू होने पर, अगर फ़ाइल फ़ोल्डर रूट पर WORKSPACE.bzlmod फ़ाइल भी मौजूद है, तो:

WORKSPACE.bzlmod लागू होती है और WORKSPACE के कॉन्टेंट को नज़रअंदाज़ कर दिया जाता है.
WorkSPACE.bzlmod फ़ाइल में कोई प्रीफ़िक्स या सफ़िक्स नहीं जोड़ा जाता.

WORKSPACE.bzlmod फ़ाइल का इस्तेमाल करने से माइग्रेशन आसान हो सकता है, क्योंकि:

Bzlmod बंद होने पर, आपको मूल WORKSPACE फ़ाइल से डिपेंडेंसी फ़ेच करनी होंगी.
Bzlmod चालू होने पर, WORKSPACE.bzlmod की मदद से माइग्रेट करने के लिए बची हुई डिपेंडेंसी को बेहतर तरीके से ट्रैक किया जा सकता है.

रिपॉज़िटरी किसको दिखे

Bzlmod यह नियंत्रित कर सकता है कि दिए गए रिपॉज़िटरी से कौनसे दूसरे रिपॉज़िटरी दिखाई दें. ज़्यादा जानकारी के लिए डेटा स्टोर करने की जगह के नाम और सख्त डेटा देखें.

यहां पर Workspace का इस्तेमाल करते समय, अलग-अलग तरह के डेटा स्टोर करने की जगहों से रिपॉज़िटरी दिखने की स्थिति के बारे में खास जानकारी दी गई है.

	मुख्य डेटा स्टोर करने की जगह से	Bazel मॉड्यूल के डेटा स्टोर करने की सुविधा से	मॉड्यूल एक्सटेंशन डेटा स्टोर करने की सुविधा से	Workspace के डेटा स्टोर करने की जगहों से
मुख्य डेटा स्टोर करने की जगह	दिख रहा है	अगर रूट मॉड्यूल डायरेक्ट डिपेंडेंसी है	अगर रूट मॉड्यूल, मॉड्यूल एक्सटेंशन को होस्ट करने वाले मॉड्यूल पर सीधे तौर पर निर्भर है, तो	दिख रहा है
Bazel मॉड्यूल का डेटा स्टोर करना	डायरेक्ट डिप	डायरेक्ट डिप	मॉड्यूल एक्सटेंशन को होस्ट करने वाले मॉड्यूल का डायरेक्ट डिप	रूट मॉड्यूल के डायरेक्ट डिप
मॉड्यूल एक्सटेंशन को फिर से उपलब्ध कराना	डायरेक्ट डिप	डायरेक्ट डिप	मॉड्यूल एक्सटेंशन को होस्ट करने वाले मॉड्यूल का डायरेक्ट डिप + एक ही मॉड्यूल एक्सटेंशन से जनरेट किए गए सभी डेटा	रूट मॉड्यूल के डायरेक्ट डिप
Workspace डेटा स्टोर करने की जगहें	सभी दिख रहे हैं	नहीं दिख रहा है	नहीं दिख रहा है	सभी दिख रहे हैं

@bar@bar

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

सामान्य Bzlmod माइग्रेशन प्रोसेस कुछ इस तरह दिख सकती है:

Workspace में अपनी डिपेंडेंसी के बारे में जानें.
अपने प्रोजेक्ट रूट में कोई खाली MODULE.bazel फ़ाइल जोड़ें.
WORKSPACE फ़ाइल के कॉन्टेंट को बदलने के लिए, कोई खाली WORKSPACE.bzlmod फ़ाइल जोड़ें.
Bzlmod चालू करके अपने टारगेट बनाएं और देखें कि कौनसी रिपॉज़िटरी मौजूद नहीं है.
रिज़ॉल्व की गई डिपेंडेंसी फ़ाइल में, रिपॉज़िटरी (डेटा स्टोर करने की जगह) की परिभाषा देखें.
किसी मॉड्यूल एक्सटेंशन की मदद से, Bazel मॉड्यूल के तौर पर, गायब डिपेंडेंसी का परिचय दें या बाद में माइग्रेशन के लिए, इसे WORKSPACE.bzlmod में रहने दें.
चार पर वापस जाएं और सभी डिपेंडेंसी उपलब्ध होने तक इसे दोहराएं.

डेटा दूसरी जगह भेजने वाला टूल

इसमें एक इंटरैक्टिव Bzlmod माइग्रेशन हेल्पर स्क्रिप्ट मौजूद है, जो शुरुआत करने में आपकी मदद कर सकती है.

स्क्रिप्ट ये काम करती है:

WorkSPACE समाधान की गई फ़ाइल जनरेट और पार्स करें.
बंद की गई फ़ाइल में डेटा स्टोर करने की जगह की जानकारी को आसानी से प्रिंट करें.
bazel बिल्ड कमांड चलाएं, पहचाने गए गड़बड़ी के मैसेज का पता लगाएं, और माइग्रेट करने का तरीका सुझाएं.
देखें कि BCR में कोई डिपेंडेंसी पहले से उपलब्ध है या नहीं.
MODULE.bazel फ़ाइल में कोई डिपेंडेंसी जोड़ें.
मॉड्यूल एक्सटेंशन की मदद से डिपेंडेंसी जोड़ें.
WORKSPACE.bzlmod फ़ाइल में कोई डिपेंडेंसी जोड़ें.

इसका इस्तेमाल करने के लिए, पक्का करें कि आपके पास Bazel रिलीज़ का नया वर्शन इंस्टॉल है और नीचे दिया कमांड चलाएं:

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>

Bazel मॉड्यूल पब्लिश करें

अगर आपका Bazel प्रोजेक्ट, दूसरे प्रोजेक्ट पर निर्भर है, तो अपने प्रोजेक्ट को Bazel Central Registry में पब्लिश किया जा सकता है.

बीसीआर में अपने प्रोजेक्ट की जांच करने के लिए, आपको प्रोजेक्ट के सोर्स संग्रह का यूआरएल चाहिए. सोर्स संग्रह बनाते समय कुछ चीज़ों का ध्यान रखें:

पक्का करें कि संग्रह किसी खास वर्शन के बारे में बताता हो.

BCR सिर्फ़ वर्शन वाले सोर्स संग्रह ही स्वीकार कर सकता है, क्योंकि Bzlmod को डिपेंडेंसी रिज़ॉल्यूशन के दौरान, वर्शन की तुलना करनी होती है.
पक्का करें कि संग्रह वाला यूआरएल स्थिर हो.

Bazel, आर्काइव के कॉन्टेंट की पुष्टि हैश वैल्यू से करता है, इसलिए आपको यह पक्का करना चाहिए कि डाउनलोड की गई फ़ाइल का चेकसम कभी न बदले. अगर यूआरएल GitHub से है, तो कृपया रिलीज़ पेज पर रिलीज़ संग्रह बनाएं और उसे अपलोड करें. GitHub, मांग पर जनरेट किए गए सोर्स आर्काइव के चेकसम की गारंटी नहीं देगा. कम शब्दों में कहें, तो https://github.com/<org>/<repo>/releases/download/... फ़ॉर्मैट वाले यूआरएल को स्थायी माना जाता है, जबकि https://github.com/<org>/<repo>/archive/... को नहीं. ज़्यादा जानकारी के लिए, GitHub Archive Checksum आउटेज देखें.
पक्का करें कि सोर्स ट्री, ओरिजनल रिपॉज़िटरी के लेआउट के हिसाब से हो.

अगर आपकी रिपॉज़िटरी बहुत बड़ी है और आपको गैर-ज़रूरी सोर्स हटाकर, कम साइज़ वाला डिस्ट्रिब्यूशन आर्काइव बनाना है, तो कृपया पक्का करें कि हटाया गया सोर्स ट्री, ओरिजनल सोर्स ट्री का सबसेट है. इससे असली उपयोगकर्ताओं के लिए, archive_override और git_override तक, मॉड्यूल को रिलीज़ न किए जाने वाले वर्शन में बदलना आसान हो जाता है.
सबडायरेक्ट्री में एक टेस्ट मॉड्यूल शामिल करें, जो आपके सबसे आम एपीआई की जांच करता हो.

टेस्ट मॉड्यूल, Bazel प्रोजेक्ट होता है. इसकी अपनी वर्कस्पेस और MODULE.bazel फ़ाइल सोर्स संग्रह की सबडायरेक्ट्री में मौजूद होती है, जो पब्लिश किए जाने वाले असल मॉड्यूल पर निर्भर होती है. इसमें उदाहरण या कुछ ऐसे इंटिग्रेशन टेस्ट होने चाहिए जिनमें आपके सबसे आम एपीआई को कवर किया गया हो. इसे सेट अप करने का तरीका जानने के लिए, टेस्ट मॉड्यूल देखें.

जब आपके पास सोर्स आर्काइव का यूआरएल तैयार हो, तब GitHub पुल रिक्वेस्ट के साथ BCR में अपना मॉड्यूल सबमिट करने के लिए, BCR योगदान के दिशा-निर्देशों का पालन करें.

हमारा सुझाव है कि अपने डेटा स्टोर करने की जगह के लिए, BCR में पब्लिश करें GitHub ऐप्लिकेशन को सेट अप करें. इससे, BCR में मॉड्यूल सबमिट करने की प्रोसेस अपने-आप पूरी हो सकेगी.

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

इस सेक्शन में कुछ सबसे सही तरीके बताए गए हैं, जिनका पालन करके आपको अपनी बाहरी डिपेंडेंसी को बेहतर ढंग से मैनेज करना चाहिए.

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

#12835 देखें, जहां टेस्ट के लिए डेवलपर डिपेंडेंसी, उन टारगेट को बनाने के लिए बेवजह को फ़ेच करती हैं जिन्हें उनकी ज़रूरत नहीं है. यह Bzlmod के लिए नहीं है, लेकिन इस तरीके को अपनाने से डेवलपर डिपेंडेंसी, सही तरीके से तय करना आसान हो जाता है.

डेवलपर डिपेंडेंसी तय करें

bazel_dep और use_extension डायरेक्टिव के लिए, dev_dependency एट्रिब्यूट को 'सही है' पर सेट किया जा सकता है, ताकि वे डिपेंडेंट प्रोजेक्ट पर लागू न हों. रूट मॉड्यूल के तौर पर, --ignore_dev_dependency फ़्लैग का इस्तेमाल करके यह पुष्टि की जा सकती है कि आपके टारगेट, अब भी डेवलपर डिपेंडेंसी के बिना बनाए जा रहे हैं या नहीं.

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

यह जानने के लिए कि क्या आपकी डिपेंडेंसी पहले से उपलब्ध हैं, Bazel Central Registry पर जाकर देखें. इसके अलावा, आपके माइग्रेशन को ब्लॉक करने वाली डिपेंडेंसी, अपवोट या पोस्ट करने के लिए GitHub पर चर्चा में शामिल हों.

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

Bzlmod की जानी-पहचानी समस्याओं के लिए, कृपया Bazel GitHub से जुड़ी समस्या की सूची देखें. नई समस्याएं दर्ज करें या सुविधा के अनुरोध करें. इनकी मदद से, माइग्रेशन को अनब्लॉक किया जा सकता है!

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

WORKSPACE बनाम Bzlmod

Bazel वर्कस्पेस का रूट तय करना

अपने bazelrc में Bzlmod चालू करें

अपने फ़ाइल फ़ोल्डर के लिए डेटा स्टोर करने की जगह का नाम डालें

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

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

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

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

तीसरे पक्ष के पैकेज मैनेजर को इंटिग्रेट करें

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

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

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

बाइंड टारगेट

माइग्रेशन

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

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

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

बिल्ट-इन डिफ़ॉल्ट डिपेंडेंसी

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

Workspace.bzlmod

रिपॉज़िटरी किसको दिखे

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

डेटा दूसरी जगह भेजने वाला टूल

Bazel मॉड्यूल पब्लिश करें

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

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

डेवलपर डिपेंडेंसी तय करें

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

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

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