Quản lý các phần phụ thuộc bên ngoài bằng Bzlmod

Báo cáo vấn đề Xem nguồn Hằng đêm · 7,3 · 7.2 · 7.1 · 7 · 6,5

Bzlmod là tên mã của hệ thống phần phụ thuộc bên ngoài mới được giới thiệu trong Bazel 5.0. Dự án này được đưa ra để giải quyết một số vấn đề một hệ thống cũ không thể khắc phục dần; xem Phần Tuyên bố vấn đề trong tài liệu thiết kế gốc để biết thêm chi tiết.

Trong Bazel 5.0, Bzlmod không được bật theo mặc định; cờ Bạn cần chỉ định --experimental_enable_bzlmod cho những dữ liệu sau để thực hiện hiệu ứng. Như tên cờ cho thấy, tính năng này hiện đang ở giai đoạn thử nghiệm; Các API và hành vi có thể thay đổi cho đến khi tính năng này chính thức ra mắt.

Để di chuyển dự án của bạn sang Bzlmod, hãy làm theo Hướng dẫn di chuyển của Bzlmod. Bạn cũng có thể tìm thấy các ví dụ về cách sử dụng Bzlmod trong kho lưu trữ ví dụ.

Mô-đun Bazel

Hệ thống phần phụ thuộc bên ngoài dựa trên WORKSPACE cũ tập trung xung quanh kho lưu trữ (hoặc kho lưu trữ), được tạo thông qua quy tắc kho lưu trữ (hoặc quy tắc kho lưu trữ). Mặc dù kho lưu trữ vẫn là một khái niệm quan trọng trong hệ thống mới, nhưng mô-đun là các đơn vị phụ thuộc cốt lõi.

Mô-đun về cơ bản là một dự án Bazel có thể có nhiều phiên bản, mỗi phiên bản trong đó xuất bản siêu dữ liệu về các mô-đun khác mà nó phụ thuộc. Đây là các khái niệm tương tự như những khái niệm quen thuộc trong các hệ thống quản lý phần phụ thuộc khác: một Maven cấu phần phần mềm (artifact), gói npm (npm), thùng (crate) hàng hoá (gargo), mô-đun Go (mô-đun) Go, v.v.

Một mô-đun chỉ đơn giản là chỉ định các phần phụ thuộc bằng cách sử dụng cặp name và version, thay vì các URL cụ thể trong WORKSPACE. Sau đó, các phần phụ thuộc được tra cứu trong một tổ chức quản lý tên miền Bazel; theo mặc định, Cơ quan đăng ký Bazel Central. Trong không gian làm việc của bạn, mỗi sau đó được chuyển thành kho lưu trữ.

MODULE.bazel

Mỗi phiên bản của mỗi mô-đun đều có một tệp MODULE.bazel khai báo tệp phần phụ thuộc và siêu dữ liệu khác. Dưới đây là ví dụ cơ bản:

module(
    name = "my-module",
    version = "1.0",
)

bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")

Tệp MODULE.bazel phải nằm ở gốc của thư mục không gian làm việc (bên cạnh tệp WORKSPACE). Không giống như tệp WORKSPACE, bạn không cần để chỉ định các phần phụ thuộc mang tính bắc cầu; thay vào đó, bạn chỉ nên chỉ định các phần phụ thuộc trực tiếp và các tệp MODULE.bazel của phần phụ thuộc là được xử lý để tự động khám phá các phần phụ thuộc bắc cầu.

Tệp MODULE.bazel tương tự như tệp BUILD vì không hỗ trợ bất kỳ tệp nào hình thức luồng điều khiển; chính sách này cũng cấm các câu lệnh load. Lệnh Các tệp MODULE.bazel hỗ trợ bao gồm:

Định dạng phiên bản

Bazel có một hệ sinh thái đa dạng và các dự án sử dụng nhiều lược đồ tạo phiên bản. Chiến lược phát hành đĩa đơn phổ biến nhất cho đến nay là SemVer, nhưng có cũng có các dự án nổi bật áp dụng các phương thức khác nhau như Abseil, có các phiên bản đều dựa trên ngày, ví dụ: 20210324.2).

Vì lý do này, Bzlmod sử dụng một phiên bản thoải mái hơn của thông số SemVer. Chiến lược phát hành đĩa đơn bao gồm:

  • SemVer quy định rằng "bản phát hành" Một phần của phiên bản phải bao gồm 3 ký tự phân khúc: MAJOR.MINOR.PATCH. Trong Bazel, yêu cầu này được nới lỏng để không giới hạn số lượng phân đoạn.
  • Trong SemVer, mỗi phân đoạn trong "bản phát hành" chỉ được phép là chữ số. Trong Bazel, chế độ này được nới lỏng để cho phép chữ cái cũng như phép so sánh ngữ nghĩa khớp với "mã nhận dạng" trong "bản thử nghiệm" phần.
  • Ngoài ra, ngữ nghĩa của việc tăng các phiên bản lớn, nhỏ và bản vá cũng không được thực thi. (Tuy nhiên, hãy xem mức độ tương thích để thông tin chi tiết về cách chúng tôi biểu thị khả năng tương thích ngược.)

Mọi phiên bản SemVer hợp lệ đều là phiên bản mô-đun Bazel hợp lệ. Ngoài ra, hai Các phiên bản SemVer a và b so sánh a < b nếu chúng giống nhau khi chúng so với các phiên bản mô-đun Bazel.

Độ phân giải của phiên bản

Vấn đề phần phụ thuộc kim cương là vấn đề chính trong phần phụ thuộc được tạo phiên bản không gian quản lý. Giả sử bạn có biểu đồ phần phụ thuộc sau:

       A 1.0
      /     \
   B 1.0    C 1.1
     |        |
   D 1.0    D 1.1

Họ nên dùng phiên bản nào của D? Để giải quyết câu hỏi này, Bzlmod sử dụng Lựa chọn phiên bản tối thiểu Thuật toán (MVS) ra mắt trong hệ thống mô-đun Go. MVS giả định rằng tất cả các phiên bản của một mô-đun có khả năng tương thích ngược, nên chỉ chọn phiên bản cao nhất phiên bản được xác định bởi bất kỳ phần phụ thuộc nào (trong ví dụ là D 1.1). Đó là "tối thiểu" vì D 1.1 ở đây là phiên bản tối thiểu có thể đáp ứng các yêu cầu của chúng tôi; ngay cả khi D 1.2 hoặc mới hơn tồn tại, chúng ta cũng không chọn chúng. Điều này có thêm lợi ích lựa chọn phiên bản có độ chân thực cao và có thể tái tạo.

Quá trình phân giải phiên bản được thực hiện cục bộ trên máy của bạn, không phải bởi sổ đăng ký.

Mức độ tương thích

Xin lưu ý rằng giả định của MVS về khả năng tương thích ngược là khả thi vì chỉ coi các phiên bản không tương thích ngược của một mô-đun là một mô-đun riêng biệt. Về mặt SemVer, điều đó có nghĩa là A 1.x và A 2.x được coi là các mô-đun riêng biệt, và có thể cùng tồn tại trong biểu đồ phần phụ thuộc đã được phân giải. Điều này lần lượt được thực hiện có thể xảy ra do phiên bản lớn được mã hoá trong đường dẫn gói trong Đảm bảo không có bất kỳ xung đột thời gian biên dịch hoặc thời gian liên kết nào.

Tại Bazel, chúng tôi không đảm bảo về điều đó. Do đó, chúng ta cần một cách để biểu thị phiên bản" số để phát hiện các phiên bản không tương thích ngược. Số này được gọi là mức độ tương thích và được chỉ định bởi từng phiên bản mô-đun trong lệnh module() tương ứng. Khi có thông tin này, chúng ta có thể báo cáo lỗi khi chúng tôi phát hiện thấy các phiên bản của cùng một mô-đun có khả năng tương thích khác nhau các cấp tồn tại trong biểu đồ phần phụ thuộc đã phân giải.

Tên kho lưu trữ

Trong Bazel, mọi phần phụ thuộc bên ngoài đều có tên kho lưu trữ. Đôi khi, cùng một phần phụ thuộc có thể được sử dụng thông qua tên kho lưu trữ khác nhau (ví dụ: cả hai Giá trị trung bình của @io_bazel_skylib và @bazel_skylib Bazel skylib), hoặc tương tự tên kho lưu trữ có thể được dùng cho các phần phụ thuộc trong từng dự án.

Trong Bzlmod, kho lưu trữ có thể được tạo bằng các mô-đun Bazel và phần mở rộng mô-đun. Để giải quyết xung đột tên kho lưu trữ, chúng tôi đang áp dụng việc liên kết kho lưu trữ trong hệ thống mới. Dưới đây là hai khái niệm quan trọng:

  • Tên kho lưu trữ chuẩn: Tên kho lưu trữ duy nhất trên toàn hệ thống cho mỗi kho lưu trữ. Đây sẽ là tên thư mục chứa kho lưu trữ.
    Tên này có cấu trúc như sau (Cảnh báo: định dạng tên chuẩn là không phải là một API bạn nên phụ thuộc, API này có thể thay đổi bất cứ lúc nào):

    • Đối với kho lưu trữ mô-đun Bazel: module_name~version
      (Ví dụ: @bazel_skylib~1.0.3)
    • Đối với kho lưu trữ tiện ích mô-đun: module_name~version~extension_name~repo_name
      (Ví dụ. @rules_cc~0.0.1~cc_configure~local_config_cc)

  • Tên kho lưu trữ gốc: Tên kho lưu trữ cần dùng trong BUILD và .bzl tệp trong một kho lưu trữ. Sự phụ thuộc tương tự có thể có sự khác biệt rõ ràng tên trong các kho lưu trữ khác nhau.
    Giá trị này được xác định như sau:

    • Đối với kho lưu trữ mô-đun Bazel: module_name theo hoặc tên do thuộc tính repo_name chỉ định trong bazel_dep.
    • Đối với kho lưu trữ tiện ích mô-đun: tên kho lưu trữ được giới thiệu qua use_repo.

Mỗi kho lưu trữ đều có một từ điển ánh xạ kho lưu trữ của các phần phụ thuộc trực tiếp, là bản đồ từ tên kho lưu trữ biểu kiến đến tên kho lưu trữ chuẩn hoá. Chúng ta sử dụng mối liên kết kho lưu trữ để phân giải tên kho lưu trữ khi tạo một . Lưu ý rằng không có xung đột giữa tên kho lưu trữ chuẩn và bạn có thể phát hiện cách sử dụng tên kho lưu trữ biểu kiến bằng cách phân tích cú pháp MODULE.bazel do đó xung đột có thể dễ dàng bị phát hiện và giải quyết mà không ảnh hưởng đến các phần phụ thuộc khác.

Phần phụ thuộc Strict

Định dạng thông số kỹ thuật mới cho phần phụ thuộc cho phép chúng tôi kiểm tra nghiêm ngặt hơn. Trong Cụ thể, chúng tôi hiện thực thi rằng một mô-đun chỉ có thể sử dụng repos được tạo từ các phần phụ thuộc trực tiếp. Điều này giúp ngăn chặn các sự cố ngoài ý muốn và khó gỡ lỗi khi một nội dung nào đó trong biểu đồ phần phụ thuộc bắc cầu thay đổi.

Phần phụ thuộc nghiêm ngặt được triển khai dựa trên liên kết kho lưu trữ. Về cơ bản, ánh xạ kho lưu trữ cho mỗi kho lưu trữ chứa tất cả phần phụ thuộc trực tiếp của nó, bất kỳ kho lưu trữ khác sẽ không hiển thị. Các phần phụ thuộc hiển thị cho mỗi kho lưu trữ được xác định như sau:

  • Kho lưu trữ mô-đun Bazel có thể xem tất cả các kho lưu trữ được giới thiệu trong tệp MODULE.bazel qua bazel_dep và use_repo.
  • Kho lưu trữ tiện ích mô-đun có thể xem tất cả phần phụ thuộc hiển thị của mô-đun cung cấp tiện ích đó, cùng với tất cả các kho lưu trữ khác do cùng một mô-đun tạo ra tiện ích.

Tổ chức quản lý tên miền

Bzlmod phát hiện các phần phụ thuộc bằng cách yêu cầu thông tin về các phần phụ thuộc đó từ Bazel tổ chức quản lý tên miền. Sổ đăng ký Bazel chỉ đơn giản là một cơ sở dữ liệu gồm các mô-đun Bazel. Chỉ tổ chức quản lý tên miền được hỗ trợ là hệ thống đăng ký chỉ mục, thư mục cục bộ hoặc máy chủ HTTP tĩnh theo một định dạng cụ thể. Trong trong tương lai, chúng tôi dự định hỗ trợ thêm cho sổ đăng ký một mô-đun, vốn chỉ đơn giản là git repos chứa nguồn và nhật ký của một dự án.

Sổ đăng ký chỉ mục

Sổ đăng ký chỉ mục là một thư mục cục bộ hoặc một máy chủ HTTP tĩnh chứa thông tin về danh sách mô-đun, bao gồm trang chủ, nhà bảo trì, Tệp MODULE.bazel của mỗi phiên bản và cách tìm nạp nguồn của mỗi tệp . Đáng chú ý là nó không cần tự phân phát các bản lưu trữ nguồn.

Sổ đăng ký chỉ mục phải tuân theo định dạng bên dưới:

  • /bazel_registry.json: Tệp JSON chứa siêu dữ liệu cho sổ đăng ký như:
    • mirrors, chỉ định danh sách bản sao để sử dụng cho bản lưu trữ nguồn.
    • module_base_path, chỉ định đường dẫn cơ sở cho các mô-đun có Loại local_repository trong tệp source.json.
  • /modules: Thư mục chứa một thư mục con cho mỗi mô-đun trong mô-đun này sổ đăng ký tên miền.
  • /modules/$MODULE: Thư mục chứa một thư mục con cho mỗi phiên bản của mô-đun này, cũng như tệp sau:
    • metadata.json: Tệp JSON chứa thông tin về mô-đun, với các trường sau:
      • homepage: URL trang chủ của dự án.
      • maintainers: Danh sách các đối tượng JSON, mỗi đối tượng tương ứng với thông tin về người duy trì mô-đun trong sổ đăng ký. Xin lưu ý rằng bài viết này không nhất thiết giống như các tác giả của dự án.
      • versions: Danh sách tất cả phiên bản của mô-đun này có trong đó sổ đăng ký này.
      • yanked_versions: Danh sách các phiên bản được kéo của mô-đun này. Chiến dịch này hiện không hoạt động, nhưng trong tương lai, các phiên bản được kéo sẽ bỏ qua hoặc dẫn đến lỗi.
  • /modules/$MODULE/$VERSION: Thư mục chứa các tệp sau:
    • MODULE.bazel: Tệp MODULE.bazel của phiên bản mô-đun này.
    • source.json: Tệp JSON chứa thông tin về cách tìm nạp nguồn của phiên bản mô-đun này.
      • Loại mặc định là "lưu trữ" với các trường sau:
        • url: URL của kho lưu trữ nguồn.
        • integrity: Tính toàn vẹn của tài nguyên phụ giá trị tổng kiểm của kho lưu trữ.
        • strip_prefix: Tiền tố thư mục cần loại bỏ khi trích xuất bản lưu trữ nguồn.
        • patches: Danh sách các chuỗi, mỗi chuỗi đặt tên cho một tệp bản vá áp dụng cho tệp lưu trữ được trích xuất. Các tệp bản vá nằm trong thư mục /modules/$MODULE/$VERSION/patches.
        • patch_strip: Giống như đối số --strip của bản vá Unix.
      • Bạn có thể thay đổi loại để sử dụng đường dẫn cục bộ với các trường sau:
        • type: local_path
        • path: Đường dẫn cục bộ đến kho lưu trữ, được tính như sau:
          • Nếu đường dẫn là một đường dẫn tuyệt đối, đường dẫn sẽ được sử dụng nguyên trạng.
          • Nếu đường dẫn là đường dẫn tương đối và module_base_path là đường dẫn tuyệt đối, đường dẫn được phân giải thành <module_base_path>/<path>
          • Nếu đường dẫn và module_base_path đều là đường dẫn tương đối, thì đường dẫn sẽ là đã phân giải thành <registry_path>/<module_base_path>/<path>. Sổ đăng ký phải được lưu trữ cục bộ và được --registry=file://<registry_path> sử dụng. Nếu không, Bazel sẽ báo lỗi.
    • patches/: Thư mục không bắt buộc chứa các tệp bản vá, chỉ được dùng khi source.json có lệnh "lưu trữ" loại.

Hệ thống đăng ký trung tâm Bazel

Bazel Central Registry (BCR) là một sổ đăng ký chỉ mục có tại bcr.bazel.build. Nội dung được hỗ trợ bởi kho lưu trữ GitHub bazelbuild/bazel-central-registry.

BCR do cộng đồng Bazel duy trì; cộng tác viên có thể gửi yêu cầu lấy dữ liệu. Xem Chính sách và quy trình của Hệ thống tên miền Trung ương Bazel.

Ngoài việc tuân theo định dạng của sổ đăng ký chỉ mục thông thường, BCR yêu cầu một tệp presubmit.yml cho từng phiên bản mô-đun (/modules/$MODULE/$VERSION/presubmit.yml). Tệp này chỉ định một vài thông tin quan trọng tạo và kiểm thử các mục tiêu có thể dùng để kiểm tra tính hợp lệ của quy tắc này phiên bản mô-đun và được sử dụng bởi quy trình CI của BCR để đảm bảo khả năng tương tác giữa các mô-đun trong BCR.

Chọn sổ đăng ký

Bạn có thể dùng cờ Bazel lặp lại --registry để chỉ định danh sách danh sách đăng ký để yêu cầu mô-đun, nhờ đó, bạn có thể thiết lập dự án để tìm nạp phần phụ thuộc của bên thứ ba hoặc hệ thống đăng ký nội bộ. Các tổ chức đăng ký trước đây mất quyền ưu tiên. Để thuận tiện, bạn có thể đặt danh sách các cờ --registry trong Tệp .bazelrc của dự án.

Tiện ích mô-đun

Tiện ích mô-đun cho phép bạn mở rộng hệ thống mô-đun bằng cách đọc dữ liệu đầu vào từ các mô-đun trên biểu đồ phần phụ thuộc, thực hiện logic cần thiết để phân giải phần phụ thuộc và cuối cùng là tạo repo bằng cách gọi các quy tắc repo. Các khái niệm tương tự nhau thực sự phù hợp với macro WORKSPACE của ngày nay, nhưng phù hợp hơn trong thế giới mô-đun và phần phụ thuộc bắc cầu.

Tiện ích mô-đun được xác định trong các tệp .bzl, giống như quy tắc kho lưu trữ hoặc Macro WORKSPACE. Các dịch vụ này sẽ không được gọi trực tiếp; thay vào đó, mỗi mô-đun có thể chỉ định các phần dữ liệu được gọi là thẻ để tiện ích đọc. Tiếp theo, sau mô-đun đã phân giải phiên bản xong, các phần mở rộng mô-đun sẽ được chạy. Mỗi tiện ích được chạy một lần sau khi phân giải mô-đun (vẫn trước khi bất kỳ phiên bản nào thực sự diễn ra) và được đọc tất cả các thẻ thuộc về nhóm đó trên toàn bộ biểu đồ phần phụ thuộc.

          [ A 1.1                ]
          [   * maven.dep(X 2.1) ]
          [   * maven.pom(...)   ]
              /              \
   bazel_dep /                \ bazel_dep
            /                  \
[ B 1.2                ]     [ C 1.0                ]
[   * maven.dep(X 1.2) ]     [   * maven.dep(X 2.1) ]
[   * maven.dep(Y 1.3) ]     [   * cargo.dep(P 1.1) ]
            \                  /
   bazel_dep \                / bazel_dep
              \              /
          [ D 1.4                ]
          [   * maven.dep(Z 1.4) ]
          [   * cargo.dep(Q 1.1) ]

Trong biểu đồ phần phụ thuộc mẫu ở trên, A 1.1 và B 1.2, v.v. là các mô-đun Bazel; bạn có thể xem mỗi phần là một tệp MODULE.bazel. Mỗi mô-đun có thể chỉ định một số các thẻ cho tiện ích mô-đun; ở đây, một số mã được chỉ định cho đuôi "maven", và một số được chỉ định cho "hàng hoá". Khi biểu đồ phần phụ thuộc này được hoàn tất (đối với ví dụ: có thể B 1.2 thực sự có bazel_dep trên D 1.3 nhưng đã được nâng cấp lên D 1.4 do C), tiện ích "maven" được chạy và trình đọc có thể đọc tất cả maven.* và sử dụng thông tin trong đó để quyết định những kho lưu trữ cần tạo. Tương tự đối với "hàng hoá" tiện ích.

Mức sử dụng tiện ích

Các tiện ích được lưu trữ trong chính các mô-đun Bazel, vì vậy, để sử dụng tiện ích trong mô-đun của mình, trước tiên bạn cần thêm bazel_dep trên mô-đun đó, sau đó gọi tích hợp sẵn use_extension để đưa nó vào phạm vi. Hãy xem ví dụ sau đây, một đoạn trích từ tệp MODULE.bazel để sử dụng một "maven" giả định tiện ích mở rộng được xác định trong Mô-đun rules_jvm_external:

bazel_dep(name = "rules_jvm_external", version = "1.0")
maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")

Sau khi đưa phần mở rộng này vào phạm vi, bạn có thể sử dụng cú pháp dấu chấm để chỉ định thẻ cho nội dung đó. Xin lưu ý rằng các thẻ này phải tuân theo giản đồ được xác định bởi các lớp thẻ tương ứng (xem định nghĩa phần mở rộng bên dưới). Sau đây là ví dụ về cách chỉ định một số thẻ maven.dep và maven.pom.

maven.dep(coord="org.junit:junit:3.0")
maven.dep(coord="com.google.guava:guava:1.2")
maven.pom(pom_xml="//:pom.xml")

Nếu tiện ích tạo ra repos mà bạn muốn sử dụng trong mô-đun của mình, hãy sử dụng Lệnh use_repo để khai báo chúng. Điều này nhằm đáp ứng điều kiện phần phụ thuộc nghiêm ngặt và tránh tên kho lưu trữ cục bộ xung đột.

use_repo(
    maven,
    "org_junit_junit",
    guava="com_google_guava_guava",
)

Các kho lưu trữ do tiện ích tạo ra đều là một phần của API, do đó, từ các thẻ mà bạn đã chỉ định, bạn sẽ biết rằng "maven" sẽ tạo kho lưu trữ có tên là "org_junit_junit" và một kho lưu trữ có tên là "com_google_guava_guava". Bằng use_repo, bạn có thể tuỳ ý đổi tên chúng trong phạm vi của mô-đun, chẳng hạn như "ổi" vào đây.

Định nghĩa phần mở rộng

Tiện ích mô-đun được xác định tương tự như quy tắc kho lưu trữ, sử dụng Hàm module_extension. Cả hai đều có chức năng triển khai; nhưng mặc dù quy tắc repo có một số thì các phần mở rộng mô-đun sẽ có một số thuộc tính tag_classes, mỗi thuộc tính có một số lượng thuộc tính. Các lớp thẻ xác định giản đồ cho thẻ mà lớp thẻ này sử dụng tiện ích. Tiếp tục ví dụ về "mave" giả định tiện ích mở rộng ở trên:

# @rules_jvm_external//:extensions.bzl
maven_dep = tag_class(attrs = {"coord": attr.string()})
maven_pom = tag_class(attrs = {"pom_xml": attr.label()})
maven = module_extension(
    implementation=_maven_impl,
    tag_classes={"dep": maven_dep, "pom": maven_pom},
)

Những nội dung khai báo này cho thấy rõ rằng thẻ maven.dep và maven.pom có thể chỉ định, sử dụng giản đồ thuộc tính được xác định ở trên.

Hàm triển khai tương tự như macro WORKSPACE, ngoại trừ việc sẽ nhận được đối tượng module_ctx và đối tượng này sẽ cấp quyền truy cập vào biểu đồ phần phụ thuộc và tất cả các thẻ liên quan. Việc triển khai thì hàm sẽ gọi quy tắc repo để tạo repos:

# @rules_jvm_external//:extensions.bzl
load("//:repo_rules.bzl", "maven_single_jar")
def _maven_impl(ctx):
  coords = []
  for mod in ctx.modules:
    coords += [dep.coord for dep in mod.tags.dep]
  output = ctx.execute(["coursier", "resolve", coords])  # hypothetical call
  repo_attrs = process_coursier(output)
  [maven_single_jar(**attrs) for attrs in repo_attrs]

Trong ví dụ trên, chúng ta sẽ tìm hiểu tất cả các mô-đun trong biểu đồ phần phụ thuộc (ctx.modules), mỗi mã trong số đó là một Đối tượng bazel_module có trường tags hiển thị tất cả các thẻ maven.* trên mô-đun. Sau đó, chúng ta gọi tiện ích CLI Coursier để liên hệ với Maven và thực hiện giải pháp. Cuối cùng, chúng tôi sử dụng độ phân giải kết quả để tạo một số repos, sử dụng maven_single_jar giả định quy tắc repo.