बाहरी डिपेंडेंसी के बेहतर विषय

वर्कस्पेस में डिपेंडेंसी को शैडो करना

जब भी हो सके, अपने प्रोजेक्ट में एक वर्शन नीति का इस्तेमाल करें. यह उन डिपेंडेंसी के लिए ज़रूरी है जिन्हें आप इकट्ठा करते हैं और अपनी फ़ाइनल बाइनरी में ले जाते हैं. अन्य मामलों में, डिपेंडेंसी को शैडो किया जा सकता है:

मेरा प्रोजेक्ट/वर्कस्पेस

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/WORKSPACE

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

B/WORKSPACE

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

A और B, दोनों डिपेंडेंसी, testrunner के अलग-अलग वर्शन पर निर्भर करती हैं. myproject/WORKSPACE में दोनों को अलग-अलग नाम देकर, myproject में दोनों को शामिल करें, ताकि कोई समस्या न हो:

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

इस तरीके का इस्तेमाल करके, डायमंड ग्रुप में भी शामिल हुआ जा सकता है. उदाहरण के लिए, अगर A और B पर एक ही डिपेंडेंसी है, लेकिन इसे अलग-अलग नामों से कॉल करें, तो उन डिपेंडेंसी को myproject/WORKSPACE में जोड़ें.

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

कमांड-लाइन से, किसी लोकल रिपॉज़िटरी को पहले से तय रिपॉज़िटरी से बदलने के लिए, --override_repository फ़्लैग का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल करने से आपका सोर्स कोड बदले बिना, बाहरी डेटा स्टोर करने की जगहों की सामग्री बदल जाती है.

उदाहरण के लिए, @foo को लोकल डायरेक्ट्री /path/to/local/foo में बदलने के लिए, --override_repository=foo=/path/to/local/foo फ़्लैग को पास करें.

इस्तेमाल के उदाहरणों में ये शामिल हैं:

डीबग करने से जुड़ी समस्याएं. उदाहरण के लिए, http_archive डेटा स्टोर करने की जगह को किसी लोकल डायरेक्ट्री में बदलने के लिए, जहां ज़्यादा आसानी से बदलाव किए जा सकते हैं.
वेंडरिंग. अगर आप ऐसे एनवायरमेंट में हैं जहां नेटवर्क कॉल नहीं किए जा सकते, तो नेटवर्क पर आधारित डेटा स्टोर करने की जगह के नियमों को ओवरराइड करें, ताकि लोकल डायरेक्ट्री पर ले जाया जा सके.

प्रॉक्सी का इस्तेमाल करना

Baज़ल, HTTPS_PROXY और HTTP_PROXY एनवायरमेंट वैरिएबल से प्रॉक्सी पते चुनता है और HTTP और HTTPS फ़ाइलों (अगर बताई गई हो) को डाउनलोड करने के लिए इनका इस्तेमाल करता है.

IPv6 के साथ काम करना

सिर्फ़ आईपीवी6 मशीनों पर, Basel बिना किसी बदलाव के डिपेंडेंसी डाउनलोड कर सकता है. हालांकि, ड्यूअल-स्टैक IPv4/IPv6 मशीनों पर, Bazel उसी तरह के समझौते का पालन करता है जिस तरह Java करता है. अगर IPv4 चालू है, तो Bazel उसे प्राथमिकता देता है. कुछ मामलों में, उदाहरण के लिए, जब आईपीवी4 नेटवर्क बाहरी पतों को ठीक नहीं कर पाता या ऐक्सेस नहीं कर पाता, तो इसकी वजह से Network unreachable अपवाद हो सकते हैं और बिल्ड काम नहीं कर सकता. इन मामलों में, java.net.preferIPv6Addresses=true सिस्टम प्रॉपर्टी का इस्तेमाल करके, IPv6 को प्राथमिकता देने के लिए, Bazel के व्यवहार को बदला जा सकता है. खास तौर पर:

--host_jvm_args=-Djava.net.preferIPv6Addresses=true स्टार्टअप विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपनी .bazelrc फ़ाइल में यह लाइन जोड़ें:

startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true
इंटरनेट से कनेक्ट करने वाले जावा बिल्ड टारगेट (जैसे, इंटिग्रेशन टेस्ट के लिए) को चलाते समय, --jvmopt=-Djava.net.preferIPv6Addresses=true टूल के लिए दिए गए फ़्लैग का इस्तेमाल करें. उदाहरण के लिए, अपनी .bazelrc फ़ाइल में यह जानकारी शामिल करें:

build --jvmopt=-Djava.net.preferIPv6Addresses
अगर डिपेंडेंसी वर्शन को हल करने के लिए rules_jvm_external का इस्तेमाल किया जा रहा है, तो Coursier के लिए JVM के विकल्प देने के लिए, COURSIER_OPTS एनवायरमेंट वैरिएबल में -Djava.net.preferIPv6Addresses=true भी जोड़ें.

ऑफ़लाइन बिल्ड

कभी-कभी आपको ऑफ़लाइन भी बिल्ड चलाना पड़ सकता है. जैसे, हवाई जहाज़ से यात्रा करते समय. इस्तेमाल के ऐसे आसान उदाहरणों के लिए, ज़रूरी डेटा स्टोर करने की जगहों को पहले से लोड करने के लिए, bazel fetch या bazel sync का इस्तेमाल करें. बिल्ड के दौरान और डेटा स्टोर करने की जगहों को फ़ेच करने की सुविधा बंद करने के लिए, --nofetch विकल्प का इस्तेमाल करें.

असल ऑफ़लाइन बिल्ड के लिए, जहां कोई दूसरी इकाई सभी ज़रूरी फ़ाइलें उपलब्ध कराती है, तो Bazel में --distdir विकल्प काम करता है. यह फ़्लैग, Bazel को उस विकल्प से तय की गई डायरेक्ट्री में सबसे पहले देखने के लिए कहता है. ऐसा तब होता है, जब कोई रिपॉज़िटरी नियम, Bazel से ctx.download या ctx.download_and_extract वाली फ़ाइल फ़ेच करने के लिए कहता है. ज़रूरी फ़ाइल का हैश योग देकर, Baze पहले यूआरएल के बेसनाम से मेल खाने वाली फ़ाइल खोजता है और हैश के मेल खाने पर लोकल कॉपी का इस्तेमाल करता है.

Baज़ल, इस तकनीक का इस्तेमाल करके डिस्ट्रिब्यूशन आर्टफ़ैक्ट से ऑफ़लाइन बूटस्ट्रैप करते हैं. ऐसा करने के लिए, यह इंटरनल distdir_tar में ज़रूरी बाहरी डिपेंडेंसी का डेटा इकट्ठा करता है.

Baज़ल, रिपॉज़िटरी नियमों में आर्बिट्रेरी कमांड को लागू करने की अनुमति देता है, बिना यह जाने कि क्या वे नेटवर्क से संपर्क करते है. इसलिए, वे पूरी तरह से ऑफ़लाइन बिल्ड लागू नहीं कर सकते. यह जांचने के लिए कि कोई बिल्ड सही तरीके से ऑफ़लाइन काम कर रहा है या नहीं, मैन्युअल रूप से नेटवर्क को ब्लॉक कर दें (जैसा कि Babel अपने बूटस्ट्रैप टेस्ट में करता है).