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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

myproject/WORKSPACE

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

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

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

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

सिर्फ़ IPv6 वाली मशीनों पर, Bazel बिना किसी बदलाव के डिपेंडेंसी डाउनलोड कर सकता है. हालांकि, ड्यूअल-स्टैक IPv4/IPv6 मशीनों पर, Bazel उसी तरह के समझौते का पालन करता है जिस तरह Java करता है. अगर IPv4 चालू है, तो Bazel उसे प्राथमिकता देता है. कुछ मामलों में, जैसे कि जब IPv4 नेटवर्क, बाहरी पतों को हल नहीं कर पाता/उन तक नहीं पहुंच पाता, तो 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 वाली फ़ाइल फ़ेच करने के लिए कहता है. ज़रूरी फ़ाइल का हैश जोड़कर, Bazel पहले यूआरएल के बेसनेम से मैच होने वाली फ़ाइल खोजता है. अगर हैश मैच होता है, तो वह लोकल कॉपी का इस्तेमाल करता है.

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

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