คำถามที่พบบ่อย

หน้านี้จะตอบคำถามที่พบบ่อยบางข้อเกี่ยวกับการขึ้นต่อกันภายนอกใน Bazel

MODULE.bazel

ฉันควรกำหนดเวอร์ชันของโมดูล Bazel อย่างไร

การตั้งค่า version ด้วยคำสั่ง module ในไฟล์เก็บถาวรต้นฉบับ MODULE.bazel อาจมีข้อเสียและผลข้างเคียงที่ไม่พึงประสงค์หลายประการหากไม่ได้รับการ จัดการอย่างระมัดระวัง

• การทำซ้ำ: การเผยแพร่โมดูลเวอร์ชันใหม่มักจะเกี่ยวข้องกับการเพิ่มเวอร์ชันใน MODULE.bazel และการติดแท็กการเผยแพร่ ซึ่งเป็น 2 ขั้นตอนแยกกันที่อาจไม่ซิงค์กัน แม้ว่าการทำงานอัตโนมัติจะช่วยลดความเสี่ยงนี้ได้ แต่การหลีกเลี่ยงปัญหาไปเลยนั้นง่ายและปลอดภัยกว่า

• ความไม่สอดคล้องกัน: ผู้ใช้ที่ลบล้างโมดูลด้วยคอมมิตที่เฉพาะเจาะจงโดยใช้ การลบล้างที่ไม่ใช่รีจิสทรีจะเห็นเวอร์ชันที่ไม่ถูกต้อง เช่น หาก MODULE.bazelในไฟล์เก็บถาวรต้นฉบับตั้งค่าversion = "0.3.0"แต่ มีการคอมมิตเพิ่มเติมตั้งแต่การเผยแพร่ครั้งนั้น ผู้ใช้ที่ลบล้าง ด้วยคอมมิตใดคอมมิตหนึ่งเหล่านั้นจะยังคงเห็น0.3.0 ในความเป็นจริง เวอร์ชันควรแสดงว่าเวอร์ชันนั้นใหม่กว่าเวอร์ชันที่เผยแพร่แล้ว เช่น 0.3.1-rc1

• ปัญหาการลบล้างที่ไม่ใช่รีจิสทรี: การใช้ค่าตัวยึดตำแหน่งอาจทำให้เกิดปัญหาเมื่อผู้ใช้ลบล้างโมดูลด้วยการลบล้างที่ไม่ใช่รีจิสทรี เช่น 0.0.0 จะไม่จัดเรียงเป็นเวอร์ชันสูงสุด ซึ่งโดยปกติแล้วจะเป็นลักษณะการทำงานที่ผู้ใช้ต้องการเมื่อทำการลบล้างที่ไม่ใช่รีจิสทรี

ดังนั้นจึงควรหลีกเลี่ยงการตั้งค่าเวอร์ชันในไฟล์เก็บถาวรต้นฉบับ MODULE.bazel แต่ให้ตั้งค่าใน MODULE.bazel ที่จัดเก็บไว้ในรีจิสทรี (เช่น Bazel Central Registry) ซึ่งเป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับเวอร์ชันโมดูลระหว่างการแก้ปัญหาทรัพยากร Dependency ภายนอกของ Bazel (ดู รีจิสทรีของ Bazel)

โดยปกติแล้วกระบวนการนี้จะเป็นแบบอัตโนมัติ เช่น ที่เก็บข้อมูลกฎตัวอย่าง rules-templateexample rule repository จะใช้การดำเนินการ bazel-contrib/publish-to-bcr publish.yaml GitHub Action เพื่อ เผยแพร่การเผยแพร่ไปยัง BCR การดำเนินการจะสร้างแพตช์สำหรับไฟล์เก็บถาวรต้นฉบับที่มีเวอร์ชันที่เผยแพร่MODULE.bazel แพตช์นี้จะจัดเก็บไว้ในรีจิสทรีและจะนำไปใช้เมื่อมีการดึงข้อมูลโมดูลระหว่างการแก้ปัญหาทรัพยากร Dependency ภายนอกของ Bazel

วิธีนี้จะช่วยให้เวอร์ชันในการเผยแพร่ในรีจิสทรีได้รับการตั้งค่าเป็น เวอร์ชันที่เผยแพร่แล้วอย่างถูกต้อง ดังนั้น bazel_dep, single_version_override และ multiple_version_override จะทำงานตามที่คาดไว้ ในขณะเดียวกันก็หลีกเลี่ยงปัญหาที่อาจเกิดขึ้นเมื่อทำการลบล้างที่ไม่ใช่รีจิสทรี เนื่องจากเวอร์ชันในไฟล์เก็บถาวรต้นฉบับจะเป็นค่าเริ่มต้น ('') ซึ่งระบบจะจัดการ อย่างถูกต้องเสมอ (เนื่องจากเป็นค่าเวอร์ชันเริ่มต้น) และจะทำงานตามที่ คาดไว้เมื่อจัดเรียง (ระบบจะถือว่าสตริงว่างเป็นเวอร์ชันสูงสุด)

ระดับความเข้ากันได้คืออะไร

คุณควรหยุดใช้ compatibility_level

การเพิ่ม compatibility_level จะทำให้เกิดความขัดแย้งของเวอร์ชันที่ผู้ใช้ปลายทางแก้ไขได้ยาก ดังนั้น ตั้งแต่ Bazel 8.6.0 และ 9.1.0 เป็นต้นไป ทั้ง compatibility_level และ max_compatibility_level จะไม่มีการดำเนินการ

ผู้ดูแลโมดูลที่ทำการเปลี่ยนแปลงที่สำคัญซึ่งทำให้เกิดการหยุดทำงานควรตรวจสอบว่าบิลด์ไม่สำเร็จจะแสดงข้อความแสดงข้อผิดพลาดที่ชัดเจนและเส้นทางการย้ายข้อมูลที่ดำเนินการได้

เอกสารประกอบเดิม:

compatibility_level ของโมดูล Bazel ควรเพิ่มขึ้น ในคอมมิตเดียวกัน ที่ทำการเปลี่ยนแปลงที่เข้ากันไม่ได้กับเวอร์ชันก่อนหน้า ("การเปลี่ยนแปลงที่ทำให้เกิดการหยุดทำงาน")

อย่างไรก็ตาม Bazel อาจแสดงข้อผิดพลาดหากตรวจพบว่ามีเวอร์ชันของ โมดูลเดียวกัน ที่มี ระดับความเข้ากันได้ที่แตกต่างกัน อยู่ในกราฟทรัพยากร Dependency ที่แก้ปัญหาแล้ว กรณีนี้อาจเกิดขึ้นได้ เช่น เมื่อโมดูล 2 โมดูลขึ้นต่อกันกับโมดูลที่ 3 เวอร์ชันที่มีระดับความเข้ากันได้ที่แตกต่างกัน

ดังนั้น การเพิ่ม compatibility_level บ่อยเกินไปอาจทำให้เกิดการหยุดชะงักอย่างมากและไม่แนะนำให้ทำ เพื่อหลีกเลี่ยงสถานการณ์นี้ ควรเพิ่ม compatibility_level เฉพาะ ในกรณีที่การเปลี่ยนแปลงที่ทำให้เกิดการหยุดทำงานส่งผลต่อกรณีการใช้งานส่วนใหญ่ และย้ายข้อมูลและ/หรือหาทางแก้ไขได้ยาก

เหตุใด MODULE.bazel จึงไม่รองรับ load

ระหว่างการแก้ปัญหาทรัพยากร Dependency ระบบจะดึงข้อมูลไฟล์ MODULE.bazel ของทรัพยากร Dependency ภายนอกทั้งหมดที่อ้างอิงจากรีจิสทรี ในขั้นตอนนี้ ระบบจะยังไม่ดึงข้อมูลไฟล์เก็บถาวรต้นฉบับของการขึ้นต่อกัน ดังนั้นหากไฟล์ MODULE.bazel load ไฟล์อื่น Bazel จะไม่มีวิธีดึงข้อมูลไฟล์นั้นจริงๆ โดยไม่ต้องดึงข้อมูลไฟล์เก็บถาวรต้นฉบับทั้งหมด โปรดทราบว่าไฟล์ MODULE.bazel เองนั้นพิเศษเนื่องจากโฮสต์อยู่ในรีจิสทรีโดยตรง

มีกรณีการใช้งานบางกรณีที่ผู้ใช้ที่ขอ load ใน MODULE.bazel มักจะสนใจ และสามารถแก้ปัญหาได้โดยไม่ต้องใช้ load

• ตรวจสอบว่าเวอร์ชันที่ระบุไว้ใน MODULE.bazel สอดคล้องกับข้อมูลเมตาของบิลด์ที่จัดเก็บไว้ที่อื่น เช่น ในไฟล์ .bzl: คุณสามารถทำได้โดยใช้วิธี native.module_version ในไฟล์ .bzl ที่โหลดจากไฟล์ BUILD
• แยกไฟล์ MODULE.bazel ขนาดใหญ่มากออกเป็นส่วนที่จัดการได้ โดยเฉพาะอย่างยิ่งสำหรับ monorepo: โมดูลรูทสามารถใช้ includeคำสั่งเพื่อแยกไฟล์ MODULE.bazel ออกเป็นหลายส่วน ด้วยเหตุผลเดียวกันนี้ เราจึงไม่อนุญาตให้ใช้ load ในไฟล์ MODULE.bazel และ include จะใช้ในโมดูลที่ไม่ใช่รูทไม่ได้
• ผู้ใช้ระบบ WORKSPACE เก่าอาจจำได้ว่ามีการประกาศ repo แล้ว load จาก repo นั้นทันทีเพื่อดำเนินการตรรกะที่ซับซ้อน ความสามารถนี้ ถูกแทนที่ด้วยส่วนขยายโมดูล

ฉันระบุช่วง SemVer สำหรับ bazel_dep ได้ไหม

ไม่ได้ ตัวจัดการแพ็กเกจอื่นๆ บางตัว เช่น npm และ Cargo รองรับช่วงเวอร์ชัน (โดยนัยหรือโดยชัดแจ้ง) และมักจะต้องใช้ตัวแก้ปัญหาข้อจำกัด (ทำให้ผู้ใช้คาดการณ์เอาต์พุตได้ยากขึ้น) และทำให้การแก้ปัญหาเวอร์ชันไม่สามารถทำซ้ำได้หากไม่มีไฟล์ล็อก

Bazel ใช้การเลือกเวอร์ชันขั้นต่ำเหมือนกับ Go ซึ่งในทางตรงกันข้ามจะทำให้คาดการณ์เอาต์พุตได้ง่ายและรับประกัน ความสามารถในการทำซ้ำ นี่คือข้อแลกเปลี่ยนที่ตรงกับเป้าหมายการออกแบบของ Bazel

นอกจากนี้ เวอร์ชันโมดูล Bazel ยังเป็น ซูเปอร์เซ็ตของ SemVer ดังนั้นสิ่งที่สมเหตุสมผลในสภาพแวดล้อม SemVer ที่เข้มงวดจึงไม่สามารถนำไปใช้กับเวอร์ชันโมดูล Bazel ได้เสมอไป

ฉันจะรับเวอร์ชันล่าสุดสำหรับ bazel_dep โดยอัตโนมัติได้ไหม

ผู้ใช้บางรายถามเป็นครั้งคราวว่าสามารถระบุ bazel_dep(name = "foo", version = "latest") เพื่อรับเวอร์ชันล่าสุดของการขึ้นต่อกันโดยอัตโนมัติได้ไหม ซึ่ง คล้ายกับ คำถามเกี่ยวกับช่วง SemVer และคำตอบก็คือ ไม่ได้เช่นกัน

โซลูชันที่แนะนำคือให้การทำงานอัตโนมัติดูแลเรื่องนี้ เช่น ตัวอย่างเช่น Renovate รองรับ โมดูล Bazel

บางครั้งผู้ใช้ที่ถามคำถามนี้ต้องการวิธีวนซ้ำอย่างรวดเร็วระหว่างการพัฒนาในเครื่อง ซึ่งทำได้โดยใช้ a local_path_override.

ทำไมจึงมี use_repo มากมาย

การใช้งานส่วนขยายโมดูลในไฟล์ MODULE.bazel บางครั้งมาพร้อมกับคำสั่ง use_repo ขนาดใหญ่ ตัวอย่างเช่น การใช้งานทั่วไปของ go_deps ส่วนขยาย จาก gazelle อาจมีลักษณะดังนี้

go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
use_repo(
    go_deps,
    "com_github_gogo_protobuf",
    "com_github_golang_mock",
    "com_github_golang_protobuf",
    "org_golang_x_net",
    ...  # potentially dozens of lines...
)

คำสั่ง use_repo ที่ยาวอาจดูซ้ำซ้อน เนื่องจากข้อมูลน่าจะอยู่ในไฟล์ go.mod ที่อ้างอิงอยู่แล้ว

เหตุผลที่ Bazel ต้องการคำสั่ง use_repo นี้ก็คือ Bazel จะเรียกใช้ส่วนขยายโมดูลแบบเลซี่ นั่นคือ ระบบจะเรียกใช้ส่วนขยายโมดูลก็ต่อเมื่อมีการสังเกตผลลัพธ์ของส่วนขยายนั้น เนื่องจาก "เอาต์พุต" ของส่วนขยายโมดูลคือคำจำกัดความของ repo ซึ่งหมายความว่าเราจะเรียกใช้ส่วนขยายโมดูลก็ต่อเมื่อมีการขอ repo ที่ส่วนขยายนั้นกำหนดไว้ (เช่น หากมีการสร้างเป้าหมาย @org_golang_x_net//:foo ในตัวอย่างข้างต้น) อย่างไรก็ตาม เราจะไม่ทราบว่าส่วนขยายโมดูลจะกำหนด repo ใดบ้างจนกว่าจะเรียกใช้ส่วนขยายนั้น นี่คือจุดที่คำสั่ง use_repo เข้ามามีบทบาท ผู้ใช้สามารถบอก Bazel ได้ว่าต้องการให้ส่วนขยายสร้าง repo ใดบ้าง แล้ว Bazel จะเรียกใช้ส่วนขยายก็ต่อเมื่อมีการใช้ repo ที่เฉพาะเจาะจงเหล่านี้

ส่วนขยายโมดูลสามารถส่งคืน ออบเจ็กต์ extension_metadata จากฟังก์ชันการใช้งานเพื่อช่วยดูแลคำสั่ง use_repo นี้ ผู้ใช้สามารถเรียกใช้คำสั่ง bazel mod tidy เพื่ออัปเดตคำสั่ง use_repo สำหรับส่วนขยายโมดูลเหล่านี้

การย้ายข้อมูล Bzlmod

ระบบจะประเมิน MODULE.bazel หรือ WORKSPACE ก่อน

เมื่อตั้งค่าทั้ง --enable_bzlmod และ --enable_workspace ก็เป็นเรื่องปกติที่จะสงสัยว่าระบบใดจะได้รับการตรวจสอบก่อน คำตอบสั้นๆ คือระบบจะประเมิน MODULE.bazel (Bzlmod) ก่อน

คำตอบแบบยาวคือ "ระบบใดได้รับการประเมินก่อน" ไม่ใช่คำถามที่ถูกต้องที่จะ ถาม แต่คำถามที่ถูกต้องที่จะถามคือในบริบทของ repo ที่มี ชื่อที่ชัดเจน @@foo ชื่อ repo ที่ปรากฏ @bar จะแก้ปัญหาเป็นอะไร หรือการแมป repo ของ @@base คืออะไร

ป้ายกำกับที่มีชื่อ repo ที่ปรากฏ (นำหน้าด้วย @ เดียว) อาจอ้างอิงถึงสิ่งต่างๆ ได้โดยขึ้นอยู่กับบริบทที่ใช้แก้ปัญหา เมื่อเห็นป้ายกำกับ @bar//:baz และสงสัยว่าป้ายกำกับนั้นชี้ไปที่ใด คุณต้องค้นหา repo บริบทก่อน เช่น หากป้ายกำกับอยู่ในไฟล์ BUILD ที่อยู่ใน repo @@foo แสดงว่า repo บริบทคือ @@foo

จากนั้น คุณสามารถใช้ตาราง "การมองเห็นที่เก็บข้อมูล" ในคู่มือการย้ายข้อมูลเพื่อ ดูว่า repo ใดที่ชื่อที่ปรากฏจะแก้ปัญหาได้ โดยขึ้นอยู่กับ repo บริบท

• หาก repo บริบทคือ repo หลัก (@@) ให้ทำดังนี้
  1. หาก bar เป็นชื่อ repo ที่ปรากฏซึ่งไฟล์ MODULE.bazel ของโมดูลรูทแนะนำ (ผ่าน bazel_dep, use_repo, module, use_repo_rule อย่างใดอย่างหนึ่ง) @bar จะแก้ปัญหาเป็นสิ่งที่ไฟล์ MODULE.bazel นั้นอ้าง
  2. มิเช่นนั้น หาก bar เป็น repo ที่กำหนดไว้ใน WORKSPACE (ซึ่งหมายความว่าชื่อที่ชัดเจนคือ @@bar) แล้ว @bar จะแก้ปัญหาเป็น @@bar
  3. มิเช่นนั้น @bar จะแก้ปัญหาเป็น @@[unknown repo 'bar' requested from @@] และท้ายที่สุดจะ ส่งผลให้เกิดข้อผิดพลาด
• หาก repo บริบทเป็น repo ของ Bzlmod-world (นั่นคือ repo ที่สอดคล้องกับโมดูล Bazel ที่ไม่ใช่รูท หรือสร้างขึ้นโดยส่วนขยายโมดูล) repo นั้นจะเห็นเฉพาะ repo อื่นๆ ของ Bzlmod-world เท่านั้น และจะไม่เห็น repo ของ WORKSPACE-world
  • ซึ่งรวมถึง repo ใดก็ตามที่แนะนำในส่วนขยายโมดูลที่คล้ายกับ non_module_deps ในโมดูลรูท หรือการสร้างอินสแตนซ์ use_repo_rule ในโมดูลรูท
• หาก repo บริบทกำหนดไว้ใน WORKSPACE ให้ทำดังนี้
  1. ก่อนอื่น ให้ตรวจสอบว่าคำจำกัดความของ repo บริบทมีแอตทริบิวต์ repo_mapping ที่สำคัญหรือไม่ หากมี ให้ดูการแมปก่อน (ดังนั้นสำหรับ repo ที่กำหนดไว้ด้วย repo_mapping = {"@bar": "@baz"} เราจะดู at @baz ด้านล่าง)
  2. หาก bar เป็นชื่อ repo ที่ปรากฏซึ่งไฟล์ MODULE.bazel ของโมดูลรูท แนะนำ แล้ว @bar จะแก้ปัญหาเป็นสิ่งที่ไฟล์ MODULE.bazel นั้น อ้าง (ซึ่งเหมือนกับรายการที่ 1 ในกรณี repo หลัก)
  3. มิเช่นนั้น @bar จะแก้ปัญหาเป็น @@bar ซึ่งส่วนใหญ่จะชี้ไปที่ repo bar ที่กำหนดไว้ใน WORKSPACE หากไม่มีการกำหนด repo ดังกล่าว Bazel จะแสดงข้อผิดพลาด

เวอร์ชันที่กระชับกว่ามีดังนี้

• repo ของ Bzlmod-world (ไม่รวม repo หลัก) จะเห็นเฉพาะ repo ของ Bzlmod-world เท่านั้น
• repo ของ WORKSPACE-world (รวมถึง repo หลัก) จะเห็นสิ่งที่โมดูลรูทในโลกของ Bzlmod กำหนดไว้ก่อน แล้วจึงกลับไปดู repo ของ WORKSPACE-world

โปรดทราบว่าระบบจะถือว่าป้ายกำกับในบรรทัดคำสั่ง Bazel (รวมถึงแฟล็ก Starlark, ค่าแฟล็กประเภทป้ายกำกับ และรูปแบบเป้าหมายการบิลด์/ทดสอบ) มี repo หลักเป็น repo บริบท

อื่นๆ

ฉันจะเตรียมและเรียกใช้การสร้างแบบออฟไลน์ได้อย่างไร

ใช้คำสั่ง bazel fetch เพื่อดึงข้อมูล repo ล่วงหน้า คุณสามารถใช้แฟล็ก --repo (เช่น bazel fetch --repo @foo) เพื่อดึงข้อมูล repo @foo เท่านั้น (แก้ปัญหาในบริบทของ repo หลัก โปรดดู คำถามด้านบน) หรือใช้รูปแบบเป้าหมาย (เช่น bazel fetch @foo//:bar) เพื่อดึงข้อมูลการขึ้นต่อกันแบบทรานซิทีฟทั้งหมดของ @foo//:bar (ซึ่งเทียบเท่ากับ bazel build --nobuild @foo//:bar)

หากต้องการตรวจสอบว่าไม่มีการดึงข้อมูลเกิดขึ้นระหว่างการบิลด์ ให้ใช้ --nofetch กล่าวอย่างแม่นยำคือ การดำเนินการนี้จะทำให้การพยายามเรียกใช้กฎของที่เก็บข้อมูลที่ไม่ใช่ในเครื่องไม่สำเร็จ

หากต้องการดึงข้อมูล repo และ แก้ไข repo เหล่านั้นเพื่อทดสอบในเครื่อง ให้ลองใช้ คำสั่ง bazel vendor

ฉันจะใช้พร็อกซี HTTP ได้อย่างไร

Bazel จะใช้ตัวแปรสภาพแวดล้อม http_proxy และ HTTPS_PROXY ที่โปรแกรมอื่นๆ เช่น curl ยอมรับโดยทั่วไป

ฉันจะตั้งค่าให้ Bazel เลือกใช้ IPv6 ในการตั้งค่า IPv4/IPv6 แบบ Dual-stack ได้อย่างไร

ในเครื่องที่ใช้ IPv6 เท่านั้น Bazel จะดาวน์โหลดการขึ้นต่อกันได้โดยไม่มีการเปลี่ยนแปลง อย่างไรก็ตาม ในเครื่องที่ใช้ IPv4/IPv6 แบบ Dual-stack Bazel จะใช้กฎเดียวกันกับ Java โดยเลือกใช้ IPv4 หากเปิดใช้ ในบางสถานการณ์ เช่น เมื่อเครือข่าย IPv4 แก้ปัญหา/เข้าถึงที่อยู่ภายนอกไม่ได้ กรณีนี้อาจทำให้เกิดข้อยกเว้น Network unreachable และการสร้างไม่สำเร็จ ในกรณีเหล่านี้ คุณสามารถลบล้าง ลักษณะการทำงานของ Bazel เพื่อเลือกใช้ IPv6 ได้โดยใช้ java.net.preferIPv6Addresses=true พร็อพเพอร์ตี้ ระบบ โดยเฉพาะ

• ใช้ --host_jvm_args=-Djava.net.preferIPv6Addresses=true ตัวเลือกการเริ่มต้น เช่น โดยเพิ่มบรรทัดต่อไปนี้ในไฟล์ .bazelrc

  startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

• เมื่อเรียกใช้เป้าหมายบิลด์ Java ที่ต้องเชื่อมต่อกับอินเทอร์เน็ต (เช่น สำหรับการทดสอบการผสานรวม) ให้ใช้--jvmopt=-Djava.net.preferIPv6Addresses=true แฟล็กเครื่องมือ เช่น ให้ใส่ในไฟล์ .bazelrc file ดังนี้

  build --jvmopt=-Djava.net.preferIPv6Addresses

• หากคุณใช้ rules_jvm_external สำหรับ การแก้ปัญหาเวอร์ชันของทรัพยากร Dependency ให้เพิ่ม -Djava.net.preferIPv6Addresses=true ลงใน COURSIER_OPTS ตัวแปรสภาพแวดล้อม เพื่อ ระบุตัวเลือก JVM สำหรับ Coursier

กฎของ repo สามารถเรียกใช้จากระยะไกลด้วยการดำเนินการจากระยะไกลได้ไหม

ไม่ได้ หรืออย่างน้อยก็ยังไม่ได้ ผู้ใช้ที่ใช้บริการการดำเนินการจากระยะไกลเพื่อเร่งความเร็วในการสร้างอาจสังเกตเห็นว่ากฎของ repo ยังคงเรียกใช้ในเครื่อง ตัวอย่างเช่น ระบบจะดาวน์โหลด http_archive ลงในเครื่องก่อน (โดยใช้แคชการดาวน์โหลดในเครื่องหากมี) แยกไฟล์ แล้วอัปโหลดไฟล์ต้นฉบับแต่ละไฟล์ไปยังบริการการดำเนินการจากระยะไกลเป็นไฟล์อินพุต จึงเป็นเรื่องปกติที่จะถามว่าทำไมบริการการดำเนินการจากระยะไกลจึงไม่ดาวน์โหลดและแยกไฟล์เก็บถาวรนั้น ซึ่งจะช่วยประหยัดการเดินทางไปกลับที่ไม่จำเป็น

เหตุผลส่วนหนึ่งคือ กฎของ repo (และส่วนขยายโมดูล) เปรียบเสมือน "สคริปต์" ที่ Bazel เรียกใช้เอง ตัวดำเนินการจากระยะไกลอาจไม่ได้ติดตั้ง Bazel ด้วยซ้ำ

อีกเหตุผลหนึ่งคือ Bazel มักจะต้องใช้ไฟล์ BUILD ในไฟล์เก็บถาวรที่ดาวน์โหลดและแยกไฟล์แล้วเพื่อทำการโหลดและการวิเคราะห์ ซึ่ง จะ ดำเนินการในเครื่อง

เรามีแนวคิดเบื้องต้นในการแก้ปัญหานี้โดยการปรับกฎของ repo ให้เป็นกฎการสร้าง ซึ่งจะทำให้กฎเหล่านั้นเรียกใช้จากระยะไกลได้โดยธรรมชาติ แต่ในทางกลับกันก็ทำให้เกิดข้อกังวลด้านสถาปัตยกรรมใหม่ๆ (เช่น คำสั่ง query อาจต้องเรียกใช้การดำเนินการ ซึ่งทำให้การออกแบบซับซ้อนขึ้น)

ดูการสนทนาก่อนหน้านี้เพิ่มเติมเกี่ยวกับหัวข้อนี้ได้ที่ A way to support repositories that need Bazel for being fetched