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

Nightly · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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 में जोड़ें.

कमांड लाइन से, रिपॉज़िटरी को ओवरराइड करना

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

उदाहरण के लिए, लोकल डायरेक्ट्री /path/to/local/foo पर @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 अपवाद हो सकते हैं और बिल्ड फ़ेल हो सकते हैं. ऐसे मामलों में, Bazel के व्यवहार को ओवरराइड किया जा सकता है, ताकि वह IPv6 को प्राथमिकता दे. इसके लिए, java.net.preferIPv6Addresses=true सिस्टम प्रॉपर्टी का इस्तेमाल करें. खास तौर पर, इस बारे में जानकारी मिलती है:

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

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

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

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

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