Build Foundation ने फ़ाउंडिंग सदस्यों के तौर पर लोगों को शामिल करना शुरू कर दिया है! ईमेल पाने वाली सूची में शामिल हों, रिसर्च में हिस्सा लेने से जुड़ा कानूनी समझौता पढ़ें, और रजिस्टर करें!

Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

समस्या की शिकायत करें सोर्स देखें

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

WORKSPACE की कमियों की वजह से, Bzlmod, लेगसी WORKSPACE सिस्टम की जगह ले रहा है. Bazel 8 (साल 2024 के आखिर में) में WORKSPACE फ़ाइल पहले से ही बंद है. इसे Bazel 9 (साल 2025 के आखिर में) में हटा दिया जाएगा. इस गाइड की मदद से, अपने प्रोजेक्ट को Bzlmod पर माइग्रेट किया जा सकता है. साथ ही, बाहरी डिपेंडेंसी मैनेज करने के लिए WORKSPACE को हटाया जा सकता है.

Bzlmod पर माइग्रेट क्यों करना चाहिए?

लेगसी WORKSPACE सिस्टम की तुलना में, कई फ़ायदे हैं. इससे Bazel के नेटवर्क को बेहतर तरीके से बढ़ाने में मदद मिलती है.
अगर आपका प्रोजेक्ट, अन्य प्रोजेक्ट पर निर्भर है, तो Bzlmod पर माइग्रेट करने से, उन प्रोजेक्ट के माइग्रेशन में आने वाली रुकावट दूर हो जाएगी. साथ ही, वे प्रोजेक्ट आसानी से आपके प्रोजेक्ट पर निर्भर हो पाएंगे.
Bzlmod पर माइग्रेट करना ज़रूरी है, ताकि Bazel के आने वाले वर्शन का इस्तेमाल किया जा सके. Bazel 9 में यह ज़रूरी है.

Bzlmod पर माइग्रेट करने का तरीका क्या है?

माइग्रेशन के लिए सुझाया गया तरीका:

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

WORKSPACE बनाम Bzlmod

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

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

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

WORKSPACE

# 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

workspace फ़ंक्शन का इस्तेमाल, अपने फ़ाइल फ़ोल्डर के लिए रिपॉज़िटरी का नाम तय करने के लिए किया जाता है. इससे वर्कस्पेस में मौजूद टारगेट //foo:bar को @<workspace name>//foo:bar के तौर पर रेफ़रंस किया जा सकता है. अगर इसकी जानकारी नहीं दी जाती है, तो आपके वर्कस्पेस के लिए डिफ़ॉल्ट रिपॉज़िटरी का नाम __main__ होता है.
```
## WORKSPACE
workspace(name = "com_foo_bar")
```
Bzlmod

हमारा सुझाव है कि आप एक ही वर्कस्पेस में टारगेट का रेफ़रंस दें. इसके लिए, //foo:bar सिंटैक्स का इस्तेमाल करें. हालांकि, इसमें @<repo name> का इस्तेमाल न करें. हालांकि, अगर आपको पुराने सिंटैक्स की ज़रूरत है, तो module फ़ंक्शन से तय किए गए मॉड्यूल के नाम का इस्तेमाल, रिपॉज़िटरी के नाम के तौर पर किया जा सकता है. अगर मॉड्यूल का नाम, ज़रूरी रिपॉज़िटरी के नाम से अलग है, तो रिपॉज़िटरी के नाम को बदलने के लिए, module फ़ंक्शन के repo_name एट्रिब्यूट का इस्तेमाल किया जा सकता है.
```
## MODULE.bazel
module(
    name = "bar",
    repo_name = "com_foo_bar",
)
```

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

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

WORKSPACE

WORKSPACE के साथ, Bazel प्रोजेक्ट के सोर्स डाउनलोड करने के लिए, http_archive या git_repository रिपॉज़िटरी के नियमों का इस्तेमाल करना आम बात है.
```
## 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 registry में डिपेंडेंसी उपलब्ध होने पर, 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 की किसी भी रजिस्ट्री में अब तक उपलब्ध नहीं है, तो इसे use_repo_rule या मॉड्यूल एक्सटेंशन का इस्तेमाल करके जोड़ा जा सकता है.

WORKSPACE

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.bazel फ़ाइल में 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 फ़ाइल में तय किया जा सकता है. हालांकि, 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

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

WORKSPACE

शेल टूलचेन का पता लगाने के लिए, यहां दिए गए रिपॉज़िटरी के नियम का इस्तेमाल किया गया है.

## 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

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 API सिर्फ़ 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 और WORKSPACE.bzlmod में रजिस्टर किए गए टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म, टूलचेन चुनने के दौरान प्राथमिकता के इस क्रम का पालन करते हैं. साथ ही, हर Bazel मॉड्यूल की MODULE.bazel फ़ाइल भी इसी क्रम का पालन करती है. प्राथमिकता का क्रम सबसे ज़्यादा से सबसे कम तक होता है:

टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म, रूट मॉड्यूल की MODULE.bazel फ़ाइल में रजिस्टर किए गए हों.
WORKSPACE या WORKSPACE.bzlmod फ़ाइल में रजिस्टर किए गए टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म.
टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म, उन मॉड्यूल से रजिस्टर किए जाते हैं जो रूट मॉड्यूल की (ट्रांज़िटिव) डिपेंडेंसी होते हैं.
WORKSPACE.bzlmod का इस्तेमाल न करने पर: WORKSPACE suffix में रजिस्टर किए गए टूलचेन.

स्थानीय रिपॉज़िटरी के बारे में जानकारी

आपको किसी डिपेंडेंसी को लोकल रिपॉज़िटरी के तौर पर तब शामिल करना पड़ सकता है, जब आपको डीबग करने के लिए डिपेंडेंसी के लोकल वर्शन की ज़रूरत हो या आपको अपने वर्कस्पेस में किसी डायरेक्ट्री को बाहरी रिपॉज़िटरी के तौर पर शामिल करना हो.

WORKSPACE

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 देखें. इसके बाद, मॉड्यूल एक्सटेंशन में, इससे जुड़े starlark 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 से बदलें.
- अहम जानकारी: टारगेट के बारे में काम की जानकारी पाने के लिए, bazel query --output=build --noenable_bzlmod --enable_workspace [target] कमांड का इस्तेमाल करें.
इसके अलावा, alias build rule का इस्तेमाल करें
- किसी पैकेज में यह टारगेट तय करें (जैसे, //third_party)
```
## third_party/BUILD
alias(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)
```
- //external:openssl के सभी इस्तेमाल को //third_party:openssl से बदलें.

डेटा फ़ेच करना बनाम सिंक करना

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

WORKSPACE

सिंक करने पर, सभी रिपॉज़िटरी या कॉन्फ़िगर किए गए रिपॉज़िटरी के किसी खास सेट के लिए, फ़ोर्स फ़ेच किया जाता है. वहीं, फ़ेच का इस्तेमाल सिर्फ़ किसी खास टारगेट के लिए फ़ेच करने के लिए किया जाता है.
Bzlmod

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

मैन्युअल तरीके से माइग्रेट करना

इस सेक्शन में, 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 बार इस्तेमाल किए गए
हालांकि, अगर आपका प्रोजेक्ट क्रॉस प्लैटफ़ॉर्म है, तो हो सकता है कि कुछ प्लैटफ़ॉर्म पर Bazel सिंक काम न करे. ऐसा इसलिए होता है, क्योंकि रिपॉज़िटरी के कुछ नियम सिर्फ़ उन प्लैटफ़ॉर्म पर ठीक से काम करते हैं जिन पर Bazel काम करता है.

कमांड चलाने के बाद, आपको resolved.bzl फ़ाइल में अपनी बाहरी डिपेंडेंसी की जानकारी मिलनी चाहिए.

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

आपको यह भी पता होगा कि bazel query का इस्तेमाल, इन नियमों के साथ रिपॉज़िटरी के नियमों की जांच करने के लिए किया जा सकता है

bazel query --output=build //external:<repo name>

यह ज़्यादा सुविधाजनक और तेज़ है. हालांकि, bazel query, बाहरी डिपेंडेंसी के वर्शन के बारे में गलत जानकारी दे सकती है. इसलिए, इसका इस्तेमाल करते समय सावधानी बरतें! Bzlmod की मदद से, बाहरी डिपेंडेंसी के बारे में क्वेरी करने और उनकी जांच करने के लिए, नया सबकमांड इस्तेमाल किया जाएगा.

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

अगर --experimental_repository_resolved_file से जनरेट की गई फ़ाइल की जांच की जाती है, तो आपको कई ऐसी डिपेंडेंसी मिलेंगी जिन्हें आपके WORKSPACE में तय नहीं किया गया है. ऐसा इसलिए होता है, क्योंकि Bazel, उपयोगकर्ता की WORKSPACE फ़ाइल के कॉन्टेंट में प्रीफ़िक्स और सफ़िक्स जोड़ता है, ताकि कुछ डिफ़ॉल्ट डिपेंडेंसी को इंजेक्ट किया जा सके.ये डिपेंडेंसी आम तौर पर नेटिव नियमों (जैसे, @bazel_tools, @platforms, और @remote_java_tools) के लिए ज़रूरी होती हैं. Bzlmod के साथ, इन डिपेंडेंसी को बिल्ट-इन मॉड्यूल bazel_tools के साथ पेश किया जाता है. यह Bazel के हर दूसरे मॉड्यूल के लिए डिफ़ॉल्ट डिपेंडेंसी होती है.

धीरे-धीरे माइग्रेट करने के लिए हाइब्रिड मोड

Bzlmod और 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 यह कंट्रोल कर सकता है कि किसी दी गई रिपॉज़िटरी से कौनसी अन्य रिपॉज़िटरी दिखें. ज़्यादा जानकारी के लिए, रिपॉज़िटरी के नाम और strict_deps देखें.

यहां अलग-अलग तरह की रिपॉज़िटरी के लिए, रिपॉज़िटरी की सेटिंग की खास जानकारी दी गई है. इसमें WORKSPACE को भी ध्यान में रखा गया है.

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

ध्यान दें: मॉड्यूल एक्सटेंशन से जनरेट की गई रिपॉज़िटरी @bar के लिए, अगर @foo का इस्तेमाल उसी मॉड्यूल एक्सटेंशन से जनरेट की गई किसी दूसरी रिपॉज़िटरी के रिपॉज़िटरी के नाम के तौर पर किया जाता है और मॉड्यूल एक्सटेंशन को होस्ट करने वाले मॉड्यूल की सीधी डिपेंडेंसी के तौर पर किया जाता है, तो रिपॉज़िटरी @bar के लिए, @foo का मतलब बाद वाली रिपॉज़िटरी से है.

मैन्युअल तरीके से माइग्रेट करने की प्रोसेस

Bzlmod पर माइग्रेट करने की सामान्य प्रोसेस कुछ ऐसी हो सकती है:

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

Bazel मॉड्यूल पब्लिश करना

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

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

पक्का करें कि संग्रह किसी खास वर्शन की ओर ले जा रहा हो.

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

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

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

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

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

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

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

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

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

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

डेवलपमेंट डिपेंडेंसी तय करना

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

कम्यूनिटी के डेटा माइग्रेशन की प्रोग्रेस

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

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

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

Bzlmod पर माइग्रेट क्यों करना चाहिए?

Bzlmod पर माइग्रेट करने का तरीका क्या है?

WORKSPACE बनाम Bzlmod

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

अपने bazelrc फ़ाइल में Bzlmod को चालू करें

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

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

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

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

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

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

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

टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म रजिस्टर करना

स्थानीय रिपॉज़िटरी के बारे में जानकारी

टारगेट बाइंड करना

डेटा फ़ेच करना बनाम सिंक करना

मैन्युअल तरीके से माइग्रेट करना

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

वर्कस्पेस में मौजूद फ़ाइल के साथ बाहरी डिपेंडेंसी की जांच करना

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

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

धीरे-धीरे माइग्रेट करने के लिए हाइब्रिड मोड

WORKSPACE.bzlmod

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

मैन्युअल तरीके से माइग्रेट करने की प्रोसेस

Bazel मॉड्यूल पब्लिश करना

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

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

डेवलपमेंट डिपेंडेंसी तय करना

कम्यूनिटी के डेटा माइग्रेशन की प्रोग्रेस

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

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