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

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

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

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

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

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

Workspace फ़ाइल बेज़ल प्रोजेक्ट के सोर्स रूट के तौर पर मार्क होती है, इस ज़िम्मेदारी को Basel के 6.3 और इसके बाद के वर्शन में MODULE.batz से बदल दिया गया है. Baज़ल वर्शन के साथ, 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")
```
ब्ज़ल्मोद

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

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

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

वर्कस्पेस

Workspace का इस्तेमाल करते समय, Basel प्रोजेक्ट के सोर्स डाउनलोड करने के लिए, 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 के साथ, जब तक आपकी डिपेंडेंसी Baaz Central Registry या आपकी कस्टम Bagel रजिस्ट्री में उपलब्ध है, तब तक आपके पास इस पर 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 मॉड्यूल के तौर पर बदलना

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

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

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

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

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

वर्कस्पेस

डेटा स्टोर करने के लिए बनाए गए 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 का इस्तेमाल करके, आपको परिभाषा को .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 फ़ाइल में तय किया जा सकता है. हालांकि, Baज़र के पुराने वर्शन के साथ काम करने के लिए, इसे एक अलग .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.basel फ़ाइल में डेटा स्टोर करने की जगह के बारे में एलान करना होगा.
```
## 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
    )

वर्कस्पेस

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

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

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

जब 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 की मदद से, मॉड्यूल एक्सटेंशन का इस्तेमाल करके उसी डेटा स्टोर करने की जगह को पेश किया जा सकता है. यह सुविधा, आखिरी सेक्शन में @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 फ़ाइल में रजिस्टर करने और मैक्रो को वर्कस्पेस फ़ाइल में लोड करने का विकल्प है.
```
## 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 के साथ, register_toolchains और register_execution_platforms एपीआई सिर्फ़ MODULE.basel फ़ाइल में उपलब्ध हैं. मॉड्यूल एक्सटेंशन में 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 में रजिस्टर किए गए टूलचेन और एक्ज़ीक्यूशन प्लैटफ़ॉर्म, और हर Baखाते के मॉड्यूल की MODULE.bazel फ़ाइल को, टूलचेन चुनने के दौरान प्राथमिकता के इस क्रम (सबसे ज़्यादा से सबसे कम) के हिसाब से सेट किया जाता है:

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

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

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

वर्कस्पेस

Workspace का इस्तेमाल करने पर, डेटा स्टोर करने की जगह के दो नेटिव नियमों, local_repository और new_local_repository की मदद से ऐसा किया जाता है.
```
## WORKSPACE
local_repository(
    name = "rules_java",
    path = "/Users/bazel_user/workspace/rules_java",
)
```
ब्ज़ल्मोद

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

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

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

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

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

कुछ खास टारगेट बनाने के लिए ज़रूरी बाहरी डिपेंडेंसी की जानकारी पाने के लिए.
```
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 से जनरेट की गई फ़ाइल की जांच की जाती है, तो आपको ऐसी कई डिपेंडेंसी मिलेंगी जो आपके Workspace में तय नहीं की गई हैं. ऐसा इसलिए है, क्योंकि Baज़र ने कुछ डिफ़ॉल्ट डिपेंडेंसी डालने के लिए, उपयोगकर्ता की Workspace फ़ाइल के कॉन्टेंट में प्रीफ़िक्स और सफ़िक्स जोड़े हैं, जिनकी ज़रूरत आम तौर पर नेटिव नियमों (जैसे, @bazel_tools, @platforms, और @remote_java_tools) के लिए होती है. Bzlmod की मदद से, ये डिपेंडेंसी बिल्ट-इन मॉड्यूल bazel_tools के साथ शुरू होती हैं, जो हर दूसरे बैजल मॉड्यूल के लिए डिफ़ॉल्ट डिपेंडेंसी होती है.

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

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

WORKSPACE.bzlmod

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

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

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

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

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

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

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

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

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

@bar@bar

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

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

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

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

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

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

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

इसका इस्तेमाल करने के लिए, पक्का करें कि आपके डिवाइस में Basel की नई रिलीज़ इंस्टॉल की गई हो. इसके बाद, यहां दिया गया कमांड रन करें:

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 प्रोजेक्ट दूसरे प्रोजेक्ट पर निर्भर है, तो आपके पास अपने प्रोजेक्ट को Bagel Central Registry में पब्लिश करने का विकल्प है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बाइंड टारगेट

माइग्रेशन

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

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

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

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

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

WORKSPACE.bzlmod

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

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

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

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

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

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

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

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

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

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