Panduan Migrasi Bzlmod

Laporkan masalah Lihat sumber

Karena kekurangan WORKSPACE, Bzlmod akan mengganti sistem WORKSPACE lama pada rilis Bazel mendatang. Panduan ini membantu Anda memigrasikan project ke Bzlmod dan menghapus WORKSPACE untuk mengambil dependensi eksternal.

WORKSPACE vs Bzlmod

WORKSPACE dan Bzlmod Bazel menawarkan fitur serupa dengan sintaks yang berbeda. Bagian ini menjelaskan cara bermigrasi dari fungsi WORKSPACE tertentu ke Bzlmod.

Menentukan root ruang kerja Bazel

File WORKSPACE menandai root sumber project Bazel, tanggung jawab ini digantikan dengan MODULE.bazel dalam Bazel versi 6.3 dan yang lebih baru. Pada versi Bazel sebelum 6.3, seharusnya masih ada file WORKSPACE atau WORKSPACE.bazel di root Workspace Anda, mungkin dengan komentar seperti:

  • RUANG KERJA

    # This file marks the root of the Bazel workspace.
# See MODULE.bazel for external dependencies setup.

Aktifkan Bzlmod di bazelrc Anda

.bazelrc memungkinkan Anda menetapkan tanda yang berlaku setiap kali menjalankan Bazel. Untuk mengaktifkan Bzlmod, gunakan flag --enable_bzlmod, lalu terapkan ke perintah common sehingga berlaku ke setiap perintah:

  • .bazelrc

    # Enable Bzlmod for every Bazel command
common --enable_bzlmod

Tentukan nama repositori untuk ruang kerja Anda

  • RUANG KERJA

    Fungsi workspace digunakan untuk menentukan nama repositori untuk ruang kerja Anda. Hal ini memungkinkan //foo:bar target di ruang kerja direferensikan sebagai @<workspace name>//foo:bar. Jika tidak ditentukan, nama repositori default untuk ruang kerja Anda adalah __main__.

    ## WORKSPACE
workspace(name = "com_foo_bar")

  • Bzlmod

    Sebaiknya referensikan target di ruang kerja yang sama dengan sintaksis //foo:bar tanpa @<repo name>. Namun, jika memerlukan sintaksis lama, Anda dapat menggunakan nama modul yang ditentukan oleh fungsi module sebagai nama repositori. Jika nama modul berbeda dengan nama repositori yang diperlukan, Anda dapat menggunakan atribut repo_name dari fungsi module untuk mengganti nama repositori.

    ## MODULE.bazel
module(
    name = "bar",
    repo_name = "com_foo_bar",
)

Mengambil dependensi eksternal sebagai modul Bazel

Jika dependensi Anda adalah project Bazel, Anda dapat bergantung pada dependensi tersebut sebagai modul Bazel saat dependensi juga mengadopsi Bzlmod.

  • RUANG KERJA

    Dengan WORKSPACE, biasanya Anda menggunakan aturan repositori http_archive atau git_repository untuk mendownload sumber project Bazel.

    ## WORKSPACE
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "bazel_skylib",
    urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"],
    sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa",
)
load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
bazel_skylib_workspace()

http_archive(
    name = "rules_java",
    urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"],
    sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a",
)
load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
rules_java_dependencies()
rules_java_toolchains()

    Seperti yang Anda lihat, ini adalah pola umum yang mengharuskan pengguna memuat dependensi transitif dari makro dependensi. Asumsikan bazel_skylib dan rules_java bergantung pada platform, versi dependensi platform yang tepat ditentukan oleh urutan makro.

  • Bzlmod

    Dengan Bzlmod, selama dependensi Anda tersedia di Bazel Central Registry atau registry Bazel kustom, Anda dapat mengandalkannya dengan perintah bazel_dep.

    ## MODULE.bazel
bazel_dep(name = "bazel_skylib", version = "1.4.2")
bazel_dep(name = "rules_java", version = "6.1.1")

    Bzlmod me-resolve dependensi modul Bazel secara transitif menggunakan algoritma MVS. Oleh karena itu, versi maksimal platform yang diperlukan akan otomatis dipilih.

Mengganti dependensi sebagai modul Bazel

Sebagai modul root, Anda dapat mengganti dependensi modul Bazel dengan cara yang berbeda.

Baca bagian overrides untuk informasi selengkapnya.

Anda dapat menemukan beberapa contoh penggunaan di repositori contoh.

Mengambil dependensi eksternal dengan ekstensi modul

Jika dependensi Anda bukan project Bazel atau belum tersedia di registry Bazel, Anda dapat memperkenalkannya menggunakan use_repo_rule atau ekstensi modul.

  • RUANG KERJA

    Download file menggunakan aturan repositori http_file.

    ## WORKSPACE
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")

http_file(
    name = "data_file",
    url = "http://example.com/file",
    sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
)

  • Bzlmod

    Dengan Bzlmod, Anda dapat menggunakan perintah use_repo_rule di file MODULE.bazel untuk langsung membuat instance repositori:

    ## MODULE.bazel
http_file = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
http_file(
    name = "data_file",
    url = "http://example.com/file",
    sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
)

    Di balik layar, hal ini diimplementasikan menggunakan ekstensi modul. Jika perlu melakukan logika yang lebih kompleks daripada sekadar memanggil aturan repo, Anda juga dapat mengimplementasikan ekstensi modul sendiri. Anda harus memindahkan definisi ke file .bzl, yang juga memungkinkan Anda membagikan definisi antara WORKSPACE dan Bzlmod selama periode migrasi.

    ## repositories.bzl
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def my_data_dependency():
    http_file(
        name = "data_file",
        url = "http://example.com/file",
        sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    )

    Implementasikan ekstensi modul untuk memuat makro dependensi. Anda dapat menentukannya dalam file .bzl makro yang sama, tetapi untuk menjaga kompatibilitas dengan versi Bazel yang lebih lama, sebaiknya tentukan dalam file .bzl terpisah.

    ## extensions.bzl
load("//:repositories.bzl", "my_data_dependency")
def _non_module_dependencies_impl(_ctx):
    my_data_dependency()

non_module_dependencies = module_extension(
    implementation = _non_module_dependencies_impl,
)

    Agar repositori terlihat oleh project root, Anda harus mendeklarasikan penggunaan ekstensi modul dan repositori dalam file MODULE.bazel.

    ## MODULE.bazel
non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies")
use_repo(non_module_dependencies, "data_file")

Mengatasi konflik dependensi eksternal dengan ekstensi modul

Project dapat menyediakan makro yang memperkenalkan repositori eksternal berdasarkan input dari pemanggilnya. Namun, bagaimana jika ada beberapa pemanggil dalam grafik dependensi dan hal itu menyebabkan konflik?

Asumsikan project foo menyediakan makro berikut yang menggunakan version sebagai argumen.

## repositories.bzl in foo {:#repositories.bzl-foo}
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def data_deps(version = "1.0"):
    http_file(
        name = "data_file",
        url = "http://example.com/file-%s" % version,
        # Omitting the "sha256" attribute for simplicity
    )

  • RUANG KERJA

    Dengan WORKSPACE, Anda dapat memuat makro dari @foo dan menentukan versi dependensi data yang diperlukan. Asumsikan Anda memiliki dependensi lain @bar, yang juga bergantung pada @foo, tetapi memerlukan versi dependensi data yang berbeda.

    ## WORKSPACE

# Introduce @foo and @bar.
...

load("@foo//:repositories.bzl", "data_deps")
data_deps(version = "2.0")

load("@bar//:repositories.bzl", "bar_deps")
bar_deps() # -> which calls data_deps(version = "3.0")

    Dalam hal ini, pengguna akhir harus menyesuaikan urutan makro di WORKSPACE dengan cermat untuk mendapatkan versi yang mereka butuhkan. Ini adalah salah satu masalah terbesar dalam WORKSPACE karena tidak benar-benar menyediakan cara yang tepat untuk menyelesaikan dependensi.

  • Bzlmod

    Dengan Bzlmod, penulis project foo dapat menggunakan ekstensi modul untuk menyelesaikan konflik. Sebagai contoh, anggaplah wajar untuk selalu memilih versi maksimal dependensi data yang diperlukan di antara semua modul Bazel.

    ## extensions.bzl in foo
load("//:repositories.bzl", "data_deps")

data = tag_class(attrs={"version": attr.string()})

def _data_deps_extension_impl(module_ctx):
    # Select the maximal required version in the dependency graph.
    version = "1.0"
    for mod in module_ctx.modules:
        for data in mod.tags.data:
            version = max(version, data.version)
    data_deps(version)

data_deps_extension = module_extension(
    implementation = _data_deps_extension_impl,
    tag_classes = {"data": data},
)

    ## MODULE.bazel in bar
bazel_dep(name = "foo", version = "1.0")

foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
foo_data_deps.data(version = "3.0")
use_repo(foo_data_deps, "data_file")

    ## MODULE.bazel in root module
bazel_dep(name = "foo", version = "1.0")
bazel_dep(name = "bar", version = "1.0")

foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
foo_data_deps.data(version = "2.0")
use_repo(foo_data_deps, "data_file")

    Dalam hal ini, modul root memerlukan versi data 2.0, sedangkan dependensinya bar memerlukan 3.0. Ekstensi modul di foo dapat menyelesaikan konflik ini dengan benar dan otomatis memilih versi 3.0 untuk dependensi data.

Mengintegrasikan pengelola paket pihak ketiga

Setelah bagian terakhir, karena ekstensi modul menyediakan cara untuk mengumpulkan informasi dari grafik dependensi, menjalankan logika kustom untuk menyelesaikan dependensi, dan memanggil aturan repositori untuk memperkenalkan repositori eksternal, hal ini menyediakan cara yang tepat bagi penulis aturan untuk menyempurnakan kumpulan aturan yang mengintegrasikan pengelola paket untuk bahasa tertentu.

Baca halaman ekstensi modul untuk mempelajari lebih lanjut cara menggunakan ekstensi modul.

Berikut adalah daftar kumpulan aturan yang sudah mengadopsi Bzlmod untuk mengambil dependensi dari berbagai pengelola paket:

Contoh minimal yang mengintegrasikan pengelola paket pseudo tersedia di repositori contoh.

Mendeteksi toolchain di mesin host

Saat aturan build Bazel perlu mendeteksi toolchain yang tersedia di mesin host, aturan tersebut akan menggunakan aturan repositori untuk memeriksa mesin host dan membuat info toolchain sebagai repositori eksternal.

  • RUANG KERJA

    Dengan aturan repositori berikut untuk mendeteksi toolchain shell.

    ## local_config_sh.bzl
def _sh_config_rule_impl(repository_ctx):
    sh_path = get_sh_path_from_env("SH_BIN_PATH")

    if not sh_path:
        sh_path = detect_sh_from_path()

    if not sh_path:
        sh_path = "/shell/binary/not/found"

    repository_ctx.file("BUILD", """
load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain")
sh_toolchain(
    name = "local_sh",
    path = "{sh_path}",
    visibility = ["//visibility:public"],
)
toolchain(
    name = "local_sh_toolchain",
    toolchain = ":local_sh",
    toolchain_type = "@bazel_tools//tools/sh:toolchain_type",
)
""".format(sh_path = sh_path))

sh_config_rule = repository_rule(
    environ = ["SH_BIN_PATH"],
    local = True,
    implementation = _sh_config_rule_impl,
)

    Anda dapat memuat aturan repositori di WORKSPACE.

    ## WORKSPACE
load("//:local_config_sh.bzl", "sh_config_rule")
sh_config_rule(name = "local_config_sh")

  • Bzlmod

    Dengan Bzlmod, Anda dapat memperkenalkan repositori yang sama menggunakan ekstensi modul, yang mirip dengan memperkenalkan repositori @data_file di bagian terakhir.

    ## local_config_sh_extension.bzl
load("//:local_config_sh.bzl", "sh_config_rule")

sh_config_extension = module_extension(
    implementation = lambda ctx: sh_config_rule(name = "local_config_sh"),
)

    Kemudian gunakan ekstensi dalam file MODULE.bazel.

    ## MODULE.bazel
sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
use_repo(sh_config_ext, "local_config_sh")

Mendaftarkan toolchain & platform eksekusi

Setelah bagian terakhir, setelah memperkenalkan informasi toolchain hosting repositori (misalnya local_config_sh), Anda mungkin ingin mendaftarkan toolchain.

  • RUANG KERJA

    Dengan WORKSPACE, Anda dapat mendaftarkan toolchain dengan cara berikut.

    1. Anda dapat mendaftarkan file .bzl toolchain dan memuat makro dalam file WORKSPACE.

      ## local_config_sh.bzl
def sh_configure():
    sh_config_rule(name = "local_config_sh")
    native.register_toolchains("@local_config_sh//:local_sh_toolchain")

      ## WORKSPACE
load("//:local_config_sh.bzl", "sh_configure")
sh_configure()

    2. Atau daftarkan toolchain di file WORKSPACE secara langsung.

      ## WORKSPACE
load("//:local_config_sh.bzl", "sh_config_rule")
sh_config_rule(name = "local_config_sh")
register_toolchains("@local_config_sh//:local_sh_toolchain")

  • Bzlmod

    Dengan Bzlmod, register_toolchains dan register_execution_platforms API hanya tersedia dalam file MODULE.bazel. Anda tidak dapat memanggil native.register_toolchains dalam ekstensi modul.

    ## MODULE.bazel
sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
use_repo(sh_config_ext, "local_config_sh")
register_toolchains("@local_config_sh//:local_sh_toolchain")

Toolchain dan platform eksekusi yang terdaftar di WORKSPACE, WORKSPACE.bzlmod, dan setiap file MODULE.bazel modul Bazel mengikuti urutan prioritas ini selama pemilihan toolchain (dari tertinggi hingga terendah):

  1. toolchain dan platform eksekusi yang terdaftar dalam file MODULE.bazel modul root.
  2. toolchain dan platform eksekusi yang terdaftar dalam file WORKSPACE atau WORKSPACE.bzlmod.
  3. toolchain dan platform eksekusi yang didaftarkan oleh modul yang merupakan dependensi (transitif) modul root.
  4. jika tidak menggunakan WORKSPACE.bzlmod: toolchain yang terdaftar dalam akhiran WORKSPACE.

Memperkenalkan repositori lokal

Anda mungkin perlu memperkenalkan dependensi sebagai repositori lokal saat memerlukan versi lokal dependensi untuk proses debug atau ingin menyertakan direktori di ruang kerja Anda sebagai repositori eksternal.

  • RUANG KERJA

    Dengan WORKSPACE, hal ini dapat dilakukan dengan dua aturan repositori native, local_repository dan new_local_repository.

    ## WORKSPACE
local_repository(
    name = "rules_java",
    path = "/Users/bazel_user/workspace/rules_java",
)

  • Bzlmod

    Dengan Bzlmod, Anda dapat menggunakan local_path_override untuk mengganti modul dengan jalur lokal.

    ## MODULE.bazel
bazel_dep(name = "rules_java")
local_path_override(
    module_name = "rules_java",
    path = "/Users/bazel_user/workspace/rules_java",
)

    Anda juga dapat memperkenalkan repositori lokal dengan ekstensi modul. Namun, Anda tidak dapat memanggil native.local_repository dalam ekstensi modul. Ada upaya berkelanjutan untuk mengaktifkan semua aturan repositori native (lihat #18285 untuk mengetahui progres). Kemudian, Anda dapat memanggil local_repository starlark yang sesuai dalam ekstensi modul. Menerapkan versi kustom aturan repositori local_repository juga merupakan hal yang mudah jika Anda mengalami masalah pemblokiran.

Mengikat target

Aturan bind di WORKSPACE tidak digunakan lagi dan tidak didukung di Bzlmod. Ini diperkenalkan untuk memberi target alias dalam paket //external khusus. Semua pengguna yang bergantung pada hal ini harus dimigrasikan.

Misalnya, jika Anda memiliki

## WORKSPACE
bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

Hal ini memungkinkan target lain bergantung pada //external:openssl. Anda dapat beralih dari titik ini dengan:

  • Ganti semua penggunaan //external:openssl dengan @my-ssl//src:openssl-lib.

  • Atau gunakan aturan build alias

    • Tentukan target berikut dalam sebuah paket (misalnya, //third_party)

      ## third_party/BUILD
alias(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

    • Ganti semua penggunaan //external:openssl dengan //third_party:openssl.

Ambil versus Sinkronkan

Perintah ambil dan sinkronisasi digunakan untuk mendownload repositori eksternal secara lokal dan terus mengupdatenya. Terkadang, juga untuk mengizinkan pembuatan secara offline menggunakan flag --nofetch setelah mengambil semua repositori yang diperlukan untuk build.

  • RUANG KERJA

    Sinkronisasi melakukan pengambilan paksa untuk semua repositori, atau untuk rangkaian repositori tertentu yang dikonfigurasi, sedangkan pengambilan hanya digunakan untuk mengambil target tertentu.

  • Bzlmod

    Perintah sinkronisasi tidak berlaku lagi, tetapi pengambilan menawarkan berbagai opsi. Anda dapat mengambil target, repositori, kumpulan repo yang dikonfigurasi, atau semua repositori yang terlibat dalam resolusi dependensi dan ekstensi modul Anda. Hasil pengambilan disimpan di cache dan untuk memaksa pengambilan, Anda harus menyertakan opsi --force selama proses pengambilan.

Migrasi

Bagian ini memberikan informasi dan panduan berguna untuk proses migrasi Bzlmod Anda.

Mengetahui dependensi Anda di WORKSPACE

Langkah pertama migrasi adalah memahami dependensi apa yang Anda miliki. Mungkin sulit untuk mengetahui dependensi persis apa yang diperkenalkan dalam file WORKSPACE karena dependensi transitif sering dimuat dengan makro *_deps.

Memeriksa dependensi eksternal dengan file workspace yang telah di-resolve

Untungnya, flag --experimental_repository_resolved_file dapat membantu. Flag ini pada dasarnya menghasilkan "file kunci" dari semua dependensi eksternal yang diambil dalam perintah Bazel terakhir Anda. Anda dapat menemukan detail selengkapnya di postingan blog ini.

Fungsi ini dapat digunakan dengan dua cara:

  1. Untuk mengambil info dependensi eksternal yang diperlukan untuk membangun target tertentu.

    bazel clean --expunge
bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar

  2. Untuk mengambil info semua dependensi eksternal yang ditentukan dalam file WORKSPACE.

    bazel clean --expunge
bazel sync --experimental_repository_resolved_file=resolved.bzl

    Dengan perintah bazel sync, Anda dapat mengambil semua dependensi yang ditentukan dalam file WORKSPACE, yang meliputi:

    • bind penggunaan
    • Penggunaan register_toolchains & register_execution_platforms

    Namun, jika project Anda adalah lintas platform, sinkronisasi bazel dapat terputus pada platform tertentu karena beberapa aturan repositori hanya dapat berjalan dengan benar pada platform yang didukung.

Setelah menjalankan perintah, Anda akan memiliki informasi dependensi eksternal di file resolved.bzl.

Memeriksa dependensi eksternal dengan bazel query

Anda mungkin juga tahu bazel query dapat digunakan untuk memeriksa aturan repositori dengan

bazel query --output=build //external:<repo name>

Meskipun lebih praktis dan cepat, kueri bazel dapat menentukan versi dependensi eksternal, jadi berhati-hatilah saat menggunakannya. Kueri dan pemeriksaan dependensi eksternal dengan Bzlmod akan dilakukan dengan subperintah baru.

Dependensi {i>default<i} bawaan

Jika memeriksa file yang dihasilkan oleh --experimental_repository_resolved_file, Anda akan menemukan banyak dependensi yang tidak ditentukan di WORKSPACE Anda. Hal ini karena Bazel sebenarnya menambahkan awalan dan akhiran ke konten file WORKSPACE pengguna untuk memasukkan beberapa dependensi default, yang biasanya diperlukan oleh aturan native (misalnya @bazel_tools, @platforms, dan @remote_java_tools). Dengan Bzlmod, dependensi tersebut diperkenalkan dengan modul bawaan bazel_tools , yang merupakan dependensi default untuk setiap modul Bazel lainnya.

Mode hybrid untuk migrasi bertahap

Bzlmod dan WORKSPACE dapat berfungsi berdampingan, yang memungkinkan migrasi dependensi dari file WORKSPACE ke Bzlmod menjadi proses bertahap.

WORKSPACE.bzlmod

Selama migrasi, pengguna Bazel mungkin perlu beralih antar-build dengan dan tanpa mengaktifkan Bzlmod. Dukungan WORKSPACE.bzlmod diterapkan untuk membuat proses lebih lancar.

WORKSPACE.bzlmod memiliki sintaksis yang sama persis dengan WORKSPACE. Jika Bzlmod diaktifkan, jika file WORKSPACE.bzlmod juga ada di root workspace:

  • WORKSPACE.bzlmod berlaku dan konten WORKSPACE diabaikan.
  • Tidak ada awalan atau akhiran yang ditambahkan ke file WORKSPACE.bzlmod.

Menggunakan file WORKSPACE.bzlmod dapat membuat migrasi lebih mudah karena:

  • Jika Bzlmod dinonaktifkan, Anda akan kembali ke pengambilan dependensi dari file WORKSPACE asli.
  • Jika Bzlmod diaktifkan, Anda dapat melacak dependensi yang tersisa untuk dimigrasikan dengan WORKSPACE.bzlmod.

Visibilitas repositori

Bzlmod dapat mengontrol repositori lain mana yang terlihat dari repositori tertentu, periksa nama repositori dan dependensi ketat untuk mengetahui detail selengkapnya.

Berikut adalah ringkasan visibilitas repositori dari berbagai jenis repositori saat juga mempertimbangkan WORKSPACE.

Dari repo utama Dari repositori modul Bazel Dari repositori ekstensi modul Dari repositori WORKSPACE
Repositori utama Visibilitas Jika modul root adalah dependensi langsung Jika modul root adalah dependensi langsung dari modul yang menghosting ekstensi modul Visibilitas
Repositori modul Bazel dependensi langsung dependensi langsung Dependensi langsung dari modul yang menghosting ekstensi modul Dependensi langsung dari modul root
Repositori ekstensi modul dependensi langsung dependensi langsung Dependensi langsung dari modul yang menghosting ekstensi modul + semua repo yang dibuat oleh ekstensi modul yang sama Dependensi langsung dari modul root
Repositori WORKSPACE Semua terlihat Tidak terlihat Tidak terlihat Semua terlihat

Proses migrasi

Proses migrasi Bzlmod standar dapat terlihat seperti ini:

  1. Pahami dependensi apa yang Anda miliki di WORKSPACE.
  2. Tambahkan file MODULE.bazel kosong di root project Anda.
  3. Tambahkan file WORKSPACE.bzlmod kosong untuk mengganti konten file WORKSPACE.
  4. Buat target Anda dengan mengaktifkan Bzlmod dan periksa repositori mana yang tidak ada.
  5. Periksa definisi repositori yang tidak ada di file dependensi yang di-resolve.
  6. Masukkan dependensi yang tidak ada sebagai modul Bazel, melalui ekstensi modul, atau biarkan di WORKSPACE.bzlmod untuk migrasi berikutnya.
  7. Kembali ke nomor 4 dan ulangi hingga semua dependensi tersedia.

Alat migrasi

Ada skrip bantuan migrasi Bzlmod interaktif yang dapat membantu Anda memulai.

Skrip akan melakukan hal-hal berikut:

  • Buat dan urai file yang diselesaikan WORKSPACE.
  • Mencetak info repositori dari file yang di-resolve dengan cara yang dapat dibaca manusia.
  • Jalankan perintah build bazel, deteksi pesan error yang dikenali, dan rekomendasikan cara untuk melakukan migrasi.
  • Periksa apakah dependensi sudah tersedia di BCR.
  • Menambahkan dependensi ke file MODULE.bazel.
  • Tambahkan dependensi melalui ekstensi modul.
  • Tambahkan dependensi ke file WORKSPACE.bzlmod.

Untuk menggunakannya, pastikan Anda telah menginstal rilis Bazel terbaru, dan jalankan perintah berikut:

git clone https://github.com/bazelbuild/bazel-central-registry.git
cd <your workspace root>
<BCR repo root>/tools/migrate_to_bzlmod.py -t <your build targets>

Memublikasikan modul Bazel

Jika project Bazel Anda merupakan dependensi untuk project lain, Anda dapat memublikasikan project di Bazel Central Registry.

Agar dapat memeriksa project Anda di BCR, Anda memerlukan URL arsip sumber project tersebut. Perhatikan beberapa hal saat membuat arsip sumber:

  • Pastikan arsip mengarah ke versi tertentu.

    BCR hanya dapat menerima arsip sumber berversi karena Bzlmod perlu melakukan perbandingan versi selama resolusi dependensi.

  • Pastikan URL arsip stabil.

    Bazel memverifikasi konten arsip dengan nilai hash, jadi Anda harus memastikan bahwa checksum file yang didownload tidak pernah berubah. Jika URL berasal dari GitHub, buat dan upload arsip rilis di halaman rilis. GitHub tidak akan menjamin checksum arsip sumber yang dihasilkan sesuai permintaan. Singkatnya, URL dalam bentuk https://github.com/<org>/<repo>/releases/download/... dianggap stabil sedangkan https://github.com/<org>/<repo>/archive/... tidak. Lihat Penghentian GitHub Archive Checksum untuk mengetahui konteks selengkapnya.

  • Pastikan hierarki sumber mengikuti tata letak repositori asli.

    Jika repositori Anda sangat besar dan Anda ingin membuat arsip distribusi berukuran lebih kecil dengan menghapus sumber yang tidak diperlukan, pastikan hierarki sumber yang dihapus merupakan subset dari hierarki sumber asli. Hal ini memudahkan pengguna akhir untuk mengganti modul ke versi non-rilis dengan archive_override dan git_override.

  • Sertakan modul pengujian dalam subdirektori yang menguji API paling umum.

    Modul pengujian adalah project Bazel dengan file WORKSPACE dan MODULE.bazel tersendiri yang terletak di subdirektori arsip sumber yang bergantung pada modul sebenarnya yang akan dipublikasikan. Pengujian ini harus berisi contoh atau beberapa pengujian integrasi yang mencakup API Anda yang paling umum. Lihat modul pengujian untuk mempelajari cara menyiapkannya.

Setelah Anda menyiapkan URL arsip sumber, ikuti panduan kontribusi BCR untuk mengirimkan modul Anda ke BCR dengan Permintaan Pull GitHub.

Sangat direkomendasikan untuk menyiapkan Aplikasi GitHub Publish to BCR agar repositori Anda dapat mengotomatiskan proses pengiriman modul ke BCR.

Praktik terbaik

Bagian ini mendokumentasikan beberapa praktik terbaik yang harus Anda ikuti untuk mengelola dependensi eksternal dengan lebih baik.

Bagi target menjadi beberapa paket yang berbeda untuk menghindari pengambilan dependensi yang tidak perlu.

Lihat #12835, di mana dependensi pengembangan untuk pengujian dipaksa diambil secara tidak perlu untuk membuat target yang tidak memerlukannya. Ini sebenarnya tidak khusus Bzlmod, tetapi mengikuti praktik ini akan mempermudah penentuan dependensi dev dengan benar.

Menentukan dependensi dev

Anda dapat menetapkan atribut dev_dependency ke benar untuk perintah bazel_dep dan use_extension agar tidak diterapkan ke project dependen. Sebagai modul root, Anda dapat menggunakan flag --ignore_dev_dependency untuk memverifikasi apakah target Anda masih di-build tanpa dependensi dev.

Progres migrasi komunitas

Anda dapat memeriksa Bazel Central Registry untuk mengetahui apakah dependensi Anda sudah tersedia. Atau, Anda dapat mengikuti diskusi GitHub ini untuk memberikan suara positif atau memposting dependensi yang memblokir migrasi Anda.

Laporkan masalah

Periksa daftar masalah Bazel GitHub untuk mengetahui masalah Bzlmod umum. Jangan ragu untuk mengajukan masalah atau permintaan fitur baru yang dapat membantu membatalkan pemblokiran migrasi Anda.