Guia de migração do Bzlmod

7.3 · 7.2 · 7.1 · 7.0 · 6.5

Devido às falhas no espaço de trabalho, o Bzlmod vai substituir o sistema legado do ESPAÇO DE TRABALHO. O arquivo WORKSPACE será desativado por padrão no Bazel 8 (final de 2024) e removido no Bazel 9 (final de 2025). Este guia ajuda você a migrar seu projeto para o Bzlmod e remover o WORKSPACE para buscar dependências externas.

WORKSPACE x Bzlmod

O WORKSPACE e o Bzlmod do Bazel oferecem recursos semelhantes com sintaxe diferente. Esta seção explica como migrar de funcionalidades específicas do WORKSPACE para o Bzlmod.

Definir a raiz de um espaço de trabalho do Bazel

O arquivo WORKSPACE marca a raiz de origem de um projeto do Bazel. Essa responsabilidade é substituída por MODULE.bazel na versão 6.3 e mais recentes do Bazel. Com a versão do Bazel anterior à 6.3, ainda deve haver um arquivo WORKSPACE ou WORKSPACE.bazel na raiz do espaço de trabalho, talvez com comentários como:

  • ESPAÇO DE TRABALHO

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

Ativar o Bzlmod no bazelrc

.bazelrc permite definir flags que são aplicadas sempre que você executa o Bazel. Para ativar o Bzlmod, use a flag --enable_bzlmod e aplique-a ao comando common para que ela seja aplicada a todos os comandos:

  • .bazelrc

    # Enable Bzlmod for every Bazel command
common --enable_bzlmod

Especificar o nome do repositório para seu espaço de trabalho

  • ESPAÇO DE TRABALHO

    A função workspace é usada para especificar um nome de repositório para seu espaço de trabalho. Isso permite que um //foo:bar de destino no espaço de trabalho seja referenciado como @<workspace name>//foo:bar. Se não for especificado, o nome do repositório padrão do workspace será __main__.

    ## WORKSPACE
workspace(name = "com_foo_bar")

  • Bzlmod

    É recomendável referenciar destinos no mesmo espaço de trabalho com a sintaxe //foo:bar sem @<repo name>. No entanto, se você precisar da sintaxe antiga, use o nome do módulo especificado pela função module como o nome do repositório. Se o nome do módulo for diferente do nome do repositório necessário, use o atributo repo_name da função module para substituir o nome do repositório.

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

Buscar dependências externas como módulos do Bazel

Se a dependência for um projeto do Bazel, você poderá depender dele como um módulo do Bazel quando ele também adotar o Bzlmod.

  • ESPAÇO DE TRABALHO

    Com o WORKSPACE, é comum usar as regras de repositório http_archive ou git_repository para fazer o download das fontes do projeto 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()

    Como você pode ver, é um padrão comum que os usuários precisam carregar dependências transitivas de uma macro da dependência. Suponha que bazel_skylib e rules_java dependam de platform. A versão exata da dependência de platform é determinada pela ordem das macros.

  • Bzlmod (em inglês)

    Com o Bzlmod, desde que a dependência esteja disponível no registro central do Bazel ou no seu registro do Bazel personalizado, basta depender dela com uma diretiva bazel_dep.

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

    O Bzlmod resolve as dependências de módulo do Bazel de forma transitiva usando o algoritmo MVS. Portanto, a versão máxima necessária de platform é selecionada automaticamente.

Substituir uma dependência como um módulo do Bazel

Como módulo raiz, é possível substituir as dependências de módulo do Bazel de diferentes maneiras.

Leia a seção substituições para mais informações.

Confira alguns exemplos de uso no repositório examples.

Buscar dependências externas com extensões de módulo

Se a dependência não for um projeto do Bazel ou ainda não estiver disponível em nenhum registro do Bazel, você poderá apresentá-la usando use_repo_rule ou extensões de módulo.

  • ESPAÇO DE TRABALHO

    Faça o download de um arquivo usando a regra de repositório 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

    Com o Bzlmod, é possível usar a diretiva use_repo_rule no arquivo MODULE.bazel para instanciar repositórios diretamente:

    ## 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",
)

    Internamente, isso é implementado usando uma extensão de módulo. Se você precisar executar uma lógica mais complexa do que simplesmente invocar uma regra de repositório, também poderá implementar uma extensão de módulo. Você vai precisar mover a definição para um arquivo .bzl, que também permite compartilhar a definição entre WORKSPACE e Bzlmod durante o período de migração.

    ## 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",
    )

    Implemente uma extensão de módulo para carregar a macro de dependências. É possível defini-lo no mesmo arquivo .bzl da macro, mas, para manter a compatibilidade com versões mais antigas do Bazel, é melhor defini-lo em um arquivo .bzl separado.

    ## 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,
)

    Para tornar o repositório visível para o projeto raiz, declare os usos da extensão do módulo e do repositório no arquivo MODULE.bazel.

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

Resolver dependências externas conflitantes com a extensão do módulo

Um projeto pode fornecer uma macro que introduz repositórios externos com base nas entradas dos autores da chamada. Mas e se houver vários autores de chamadas no gráfico de dependência e eles causarem um conflito?

Suponha que o projeto foo forneça a macro a seguir, que usa version como um argumento.

## 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
    )

  • ESPAÇO DE TRABALHO

    Com o WORKSPACE, é possível carregar a macro de @foo e especificar a versão da dependência de dados necessária. Suponha que você tenha outra dependência @bar, que também depende de @foo, mas exige uma versão diferente da dependência de dados.

    ## 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")

    Nesse caso, o usuário final precisa ajustar cuidadosamente a ordem das macros no WORKSPACE para conseguir a versão necessária. Esse é um dos maiores problemas do WORKSPACE, já que ele não oferece uma maneira sensata de resolver dependências.

  • Bzlmod (em inglês)

    Com o Bzlmod, o autor do projeto foo pode usar a extensão do módulo para resolver conflitos. Por exemplo, suponha que faça sentido sempre selecionar a versão máxima necessária da dependência de dados entre todos os módulos do 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")

    Nesse caso, o módulo raiz exige a versão de dados 2.0, enquanto a dependência bar exige 3.0. A extensão do módulo em foo pode resolver corretamente esse conflito e selecionar automaticamente a versão 3.0 para a dependência de dados.

Integrar o gerenciador de pacotes de terceiros

Seguindo a última seção, como a extensão de módulo oferece uma maneira de coletar informações do gráfico de dependências, realizar uma lógica personalizada para resolver dependências e chamar regras de repositório para introduzir repositórios externos, essa é uma ótima maneira de os autores de regras aprimorarem os conjuntos de regras que integram gerenciadores de pacotes para idiomas específicos.

Leia a página Extensões de módulo para saber mais sobre como usar extensões de módulo.

Confira uma lista de conjuntos de regras que já adotaram o Bzlmod para buscar dependências de diferentes gerenciadores de pacotes:

Um exemplo mínimo que integra um pseudo gerenciador de pacotes está disponível no repositório examples.

Detectar cadeias de ferramentas na máquina host

Quando as regras de build do Bazel precisam detectar quais conjuntos de ferramentas estão disponíveis na máquina host, elas usam regras de repositório para inspecionar a máquina host e gerar informações como repositórios externos.

  • ESPAÇO DE TRABALHO

    Considere a seguinte regra de repositório para detectar um conjunto de ferramentas do 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,
)

    É possível carregar a regra do repositório no WORKSPACE.

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

  • Bzlmod (em inglês)

    Com o Bzlmod, é possível apresentar o mesmo repositório usando uma extensão de módulo, semelhante à apresentação do repositório @data_file na última seção.

    ## 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"),
)

    Em seguida, use a extensão no arquivo 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")

Registrar cadeias de ferramentas e plataformas de execução

Seguindo a última seção, após a introdução de um repositório de informações do conjunto de ferramentas (por exemplo, local_config_sh), é provável que você queira registrar o conjunto de ferramentas.

  • ESPAÇO DE TRABALHO

    Com o WORKSPACE, é possível registrar a cadeia de ferramentas das seguintes maneiras:

    1. É possível registrar o conjunto de ferramentas do arquivo .bzl e carregar a macro no arquivo de ESPAÇO DE TRABALHO.

      ## 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. Ou registre o conjunto de ferramentas no arquivo WORKSPACE diretamente.

      ## 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

    Com o Bzlmod, as APIs register_toolchains e register_execution_platforms estão disponíveis apenas no arquivo MODULE.bazel. Não é possível chamar native.register_toolchains em uma extensão de módulo.

    ## 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")

Os conjuntos de ferramentas e as plataformas de execução registrados em WORKSPACE, WORKSPACE.bzlmod e o arquivo MODULE.bazel de cada módulo do Bazel seguem esta ordem de precedência durante a seleção do conjunto de ferramentas (da mais alta para a mais baixa):

  1. toolchains e plataformas de execução registradas no arquivo MODULE.bazel do módulo raiz.
  2. conjuntos de ferramentas e plataformas de execução registrados no arquivo WORKSPACE ou WORKSPACE.bzlmod.
  3. toolchains e plataformas de execução registradas por módulos que são dependências (transitivo) do módulo raiz.
  4. ao não usar WORKSPACE.bzlmod: cadeias de ferramentas registradas no sufixo WORKSPACE.

Apresente os repositórios locais

Talvez seja necessário introduzir uma dependência como um repositório local quando você precisar de uma versão local da dependência para depuração ou quiser incorporar um diretório no seu espaço de trabalho como repositório externo.

  • ESPAÇO DE TRABALHO

    Com o WORKSPACE, isso é feito por duas regras de repositório nativo, local_repository e new_local_repository.

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

  • Bzlmod

    Com o Bzlmod, você pode usar local_path_override para substituir um módulo por um caminho local.

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

    Também é possível introduzir um repositório local com extensão de módulo. No entanto, não é possível chamar native.local_repository na extensão do módulo. Há um esforço contínuo para starlarkificar todas as regras de repositório nativo (confira #18285 para ver o progresso). Em seguida, chame o local_repository do Starlark correspondente em uma extensão de módulo. Também é trivial implementar uma versão personalizada da regra do repositório local_repository se esse for um problema de bloqueio para você.

Vincular destinos

A regra bind no WORKSPACE foi descontinuada e não tem suporte no Bzlmod. Ele foi introduzido para dar um alias a um destino no pacote especial //external. Todos os usuários que dependem disso precisam migrar.

Por exemplo, se você tiver

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

Isso permite que outras metas dependam de //external:openssl. Você pode migrar para outro local:

  • Substitua todos os usos de //external:openssl por @my-ssl//src:openssl-lib.

  • Ou use a regra de build alias

    • Defina o destino a seguir em um pacote (por exemplo, //third_party)

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

    • Substitua todos os usos de //external:openssl por //third_party:openssl.

Buscar e sincronizar

Os comandos de busca e sincronização são usados para fazer o download de repositórios externos localmente e mantê-los atualizados. Às vezes, também para permitir a criação off-line usando a flag --nofetch depois de buscar todos os repositórios necessários para uma build.

  • ESPAÇO DE TRABALHO

    A sincronização executa um fetch forçado para todos os repositórios ou para um conjunto configurado de repositórios, enquanto o fetch é somente usado para buscar um destino específico.

  • Bzlmod

    O comando de sincronização não é mais aplicável, mas o fetch oferece várias opções. É possível buscar um destino, um repositório, um conjunto de repositórios configurados ou todos os repositórios envolvidos na resolução de dependências e extensões de módulo. O resultado da busca é armazenado em cache e, para forçar uma busca, é necessário incluir a opção --force durante o processo.

Migração

Esta seção fornece informações e orientações úteis para o processo de migração do Bzlmod.

Conheça suas dependências no WORKSPACE

A primeira etapa da migração é entender quais dependências você tem. Pode ser difícil descobrir quais dependências exatas são introduzidas no arquivo WORKSPACE, porque as dependências transitivas geralmente são carregadas com macros *_deps.

Inspecionar a dependência externa com o arquivo resolvido do espaço de trabalho

Felizmente, a flag --experimental_repository_resolved_file pode ajudar. Essa flag gera essencialmente um "arquivo de bloqueio" de todas as dependências externas buscadas no último comando do Bazel. Confira mais detalhes nesta postagem do blog.

Ele pode ser usado de duas maneiras:

  1. Para buscar informações de dependências externas necessárias para criar determinados destinos.

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

  2. Para buscar informações de todas as dependências externas definidas no arquivo WORKSPACE.

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

    Com o comando bazel sync, é possível buscar todas as dependências definidas no arquivo WORKSPACE, que incluem:

    • bind usos
    • Usos de register_toolchains e register_execution_platforms

    No entanto, se o projeto for multiplataforma, a sincronização do Bazel poderá ser interrompida em determinadas plataformas, porque algumas regras do repositório só podem ser executadas corretamente em plataformas com suporte.

Depois de executar o comando, você terá informações sobre as dependências externas no arquivo resolved.bzl.

Inspecionar a dependência externa com bazel query

Você também pode saber que o bazel query pode ser usado para inspecionar regras de repositório com

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

Embora seja mais conveniente e muito mais rápido, a consulta do Bazel pode mentir sobre a versão de dependência externa, então tenha cuidado ao usá-la. A consulta e a inspeção de dependências externas com o Bzlmod será feita por um novo subcomando.

Dependências padrão integradas

Se você verificar o arquivo gerado por --experimental_repository_resolved_file, vai encontrar muitas dependências que não estão definidas no seu WORKSPACE. Isso acontece porque o Bazel adiciona prefixos e sufixos ao conteúdo do arquivo WORKSPACE do usuário para injetar algumas dependências padrão, que geralmente são exigidas por regras nativas (por exemplo, @bazel_tools, @platforms e @remote_java_tools). Com o Bzlmod, essas dependências são introduzidas com um módulo integrado bazel_tools, que é uma dependência padrão para todos os outros módulos do Bazel.

Modo híbrido para migração gradual

O Bzlmod e o WORKSPACE podem trabalhar lado a lado, o que permite que a migração de dependências do arquivo WORKSPACE para o Bzlmod seja um processo gradual.

WORKSPACE.bzlmod

Durante a migração, os usuários do Bazel podem precisar alternar entre builds com e sem o Bzlmod ativado. O suporte a WORKSPACE.bzlmod foi implementado para facilitar o processo.

WORKSPACE.bzlmod tem a mesma sintaxe de WORKSPACE. Quando o Bzlmod está ativado, se um arquivo WORKSPACE.bzlmod também existir na raiz do espaço de trabalho:

  • WORKSPACE.bzlmod entra em vigor, e o conteúdo de WORKSPACE é ignorado.
  • Nenhum prefixo ou sufixo é adicionado ao arquivo WORKSPACE.bzlmod.

O uso do arquivo WORKSPACE.bzlmod pode facilitar a migração porque:

  • Quando o Bzlmod está desativado, você volta a buscar dependências do arquivo WORKSPACE original.
  • Quando o Bzlmod está ativado, é possível acompanhar melhor quais dependências ainda precisam ser migradas com WORKSPACE.bzlmod.

Visibilidade do repositório

O Bzlmod pode controlar quais outros repositórios são visíveis em um determinado repositório. Confira nomes de repositório e dependências rígidas para mais detalhes.

Aqui está um resumo das visibilidades do repositório de diferentes tipos de repositórios, considerando também o ESPAÇO DE TRABALHO.

Do repositório principal De repositórios de módulos do Bazel De repositórios de extensões de módulo De repositórios do WORKSPACE
O repositório principal Visível Se o módulo raiz for uma dependência direta Se o módulo raiz for uma dependência direta do módulo que hospeda a extensão do módulo Visível
repositórios de módulos do Bazel Dependências diretas Dependências diretas Deps diretas do módulo que hospeda a extensão do módulo Dependências diretas do módulo raiz
Repositórios de extensão de módulo Dependências diretas Dependências diretas Deps diretas do módulo que hospeda a extensão do módulo e todos os repositórios gerados pela mesma extensão de módulo Depêndências diretas do módulo raiz
Repositórios do WORKSPACE Todos visíveis Não visível Não visível Todos visíveis

Processo de migração

Um processo de migração típico do Bzlmod pode ser assim:

  1. Entenda quais dependências você tem no ESPAÇO DE TRABALHO.
  2. Adicione um arquivo MODULE.bazel vazio na raiz do projeto.
  3. Adicione um arquivo WORKSPACE.bzlmod vazio para substituir o conteúdo do arquivo WORKSPACE.
  4. Crie seus destinos com o Bzlmod ativado e verifique qual repositório está ausente.
  5. Verifique a definição do repositório ausente no arquivo de dependência resolvido.
  6. Inclua a dependência ausente como um módulo do Bazel usando uma extensão de módulo ou deixe-a no espaço de trabalho.bzlmod para migração posterior.
  7. Volte para a versão 4 e repita até que todas as dependências estejam disponíveis.

Ferramenta de migração

Há um script auxiliar interativo de migração do Bzlmod que pode ajudar você a começar.

O script faz o seguinte:

  • Gere e analise o arquivo resolvido do WORKSPACE.
  • Imprime informações do repositório do arquivo resolvido de forma legível.
  • Executa o comando de build do Bazel, detecta mensagens de erro reconhecidas e recomenda uma maneira de migrar.
  • Verifique se uma dependência já está disponível no BCR.
  • Adicione uma dependência ao arquivo MODULE.bazel.
  • Adicionar uma dependência usando uma extensão de módulo.
  • Adicione uma dependência ao arquivo WORKSPACE.bzlmod.

Para usá-lo, verifique se você tem a versão mais recente do Bazel instalada e execute o seguinte comando:

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>

Publicar módulos do Bazel

Se o projeto do Bazel for uma dependência de outros projetos, você poderá publicar seu projeto no registro central do Bazel.

Para fazer o check-in do seu projeto no BCR, você precisa de um URL de arquivo de origem do projeto. Observe algumas coisas ao criar o arquivo de origem:

  • Verifique se o arquivo está apontando para uma versão específica.

    O BCR só pode aceitar arquivos de origem com versão porque o Bzlmod precisa realizar a comparação de versões durante a resolução de dependências.

  • Confira se o URL do arquivo é estável.

    O Bazel verifica o conteúdo do arquivo por um valor de hash. Portanto, verifique se a checksum do arquivo transferido por download nunca muda. Se o URL for do GitHub, crie e faça upload de um arquivo de lançamento na página de lançamento. O GitHub não vai garantir a soma de verificação dos arquivos de origem gerados sob demanda. Em resumo, os URLs no formato de https://github.com/<org>/<repo>/releases/download/... são considerados estáveis, enquanto https://github.com/<org>/<repo>/archive/... não é. Confira o GitHub Archive Checksum Outage para mais contexto.

  • Verifique se a árvore de origem segue o layout do repositório original.

    Caso seu repositório seja muito grande e você queira criar um arquivo de distribuição com tamanho reduzido removendo origens desnecessárias, confira se a árvore de origem removida é um subconjunto da árvore de origem original. Isso facilita que os usuários finais substituam o módulo por uma versão não lançada usando archive_override e git_override.

  • Inclua um módulo de teste em um subdiretório que teste as APIs mais comuns.

    Um módulo de teste é um projeto do Bazel com o próprio arquivo WORKSPACE e MODULE.bazel localizado em um subdiretório do arquivo de origem, que depende do módulo real a ser publicado. Ele precisa conter exemplos ou alguns testes de integração que abrangem as APIs mais comuns. Consulte módulo de teste para saber como fazer a configuração.

Quando o URL do arquivo de origem estiver pronto, siga as diretrizes de contribuição do BCR para enviar seu módulo ao BCR com uma solicitação de pull do GitHub.

É altamente recomendado configurar o app GitHub Publicar no BCR para que seu repositório automatize o processo de envio do módulo ao BCR.

Práticas recomendadas

Esta seção documenta algumas práticas recomendadas que você precisa seguir para gerenciar melhor as dependências externas.

Divida os destinos em pacotes diferentes para evitar a busca de dependências desnecessárias.

Confira #12835, em que as dependências de desenvolvimento para testes são forçadas a serem buscadas desnecessariamente para criar alvos que não precisam delas. Isso não é específico do Bzlmod, mas seguir essas práticas facilita a especificação correta das dependências de desenvolvimento.

Especificar dependências de desenvolvimento

É possível definir o atributo dev_dependency como verdadeiro para as diretivas bazel_dep e use_extension para que elas não sejam propagadas para projetos dependentes. Como módulo raiz, você pode usar a flag --ignore_dev_dependency para verificar se as metas ainda são criadas sem dependências e substituições de desenvolvimento.

Progresso da migração da comunidade

Verifique o Bazel Central Registry para descobrir se as dependências já estão disponíveis. Caso contrário, participe desta discussão do GitHub para apoiar ou publicar as dependências que estão bloqueando a migração.

Informar problemas

Confira a lista de problemas do Bazel no GitHub para ver problemas conhecidos do Bzlmod. Fique à vontade para registrar novos problemas ou solicitações de recursos que possam ajudar a desbloquear a migração.