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

หน้านี้จะตอบคำถามที่พบบ่อยบางข้อเกี่ยวกับการขึ้นต่อกันภายนอกใน 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) ซึ่งเป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับ เวอร์ชันโมดูลระหว่างการแก้ปัญหาการขึ้นต่อกันภายนอกของ Bazel (ดู รีจิสทรี ของ Bazel)

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

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

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

ระหว่างการแก้ปัญหาการขึ้นต่อกัน ระบบจะดึงข้อมูลไฟล์ MODULE.bazel ของการขึ้นต่อกันภายนอกทั้งหมดที่อ้างอิงจากรีจิสทรี ในขั้นตอนนี้ ระบบจะยังไม่ดึงข้อมูลไฟล์เก็บถาวรต้นฉบับของการขึ้นต่อกัน ดังนั้นหากไฟล์ 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-world กำหนดไว้ก่อน จากนั้นจึงกลับไปดู 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 สำหรับ การแก้ปัญหาเวอร์ชันการขึ้นต่อกัน ให้เพิ่ม -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