Devido a falhas do espaço de trabalho, o Bzlmod vai substituir o sistema legado de espaço de trabalho em versões futuras do Bazel. Este guia ajuda você a migrar seu projeto para o Bzlmod e soltar o ESPAÇO DE TRABALHO para buscar dependências externas.
WORKSPACE x Bzlmod
O ESPAÇO DE TRABALHO e o Bzlmod do Bazel oferecem recursos semelhantes com sintaxes diferentes. Esta seção explica como migrar de funcionalidades específicas do ESPAÇO DE TRABALHO 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 no Bazel versão 6.3 e mais recente. Com a versão do Bazel anterior à 6.3, ainda 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.
Especifique o nome do repositório do seu espaço de trabalho
ESPAÇO DE TRABALHO
A função
workspace
é usada para especificar um nome de repositório para o 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 para seu espaço de trabalho será__main__
.## WORKSPACE workspace(name = "com_foo_bar")
Bzlmod (em inglês)
É recomendável fazer referência a destinos no mesmo espaço de trabalho com a sintaxe
//foo:bar
sem@<repo name>
. No entanto, se você precisar da sintaxe antiga, poderá usar o nome do módulo especificado pela funçãomodule
como o nome do repositório. Se o nome do módulo for diferente do nome do repositório necessário, é possível usar o atributorepo_name
da funçãomodule
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 ESPAÇO DE TRABALHO, é comum usar as regras de repositório
http_archive
ougit_repository
para fazer o download das origens do projeto do 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 notar, é um padrão comum que os usuários precisam carregar dependências transmissivas de uma macro da dependência. Suponha que
bazel_skylib
erules_java
dependam deplatoform
. A versão exata da dependênciaplatform
é determinada pela ordem das macros.Bzlmod (em inglês)
Com o Bzlmod, desde que sua dependência esteja disponível no Bazel Central Registry ou no registro personalizado do Bazel, você pode simplesmente 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 do módulo do Bazel de forma transitiva usando o algoritmo MVS. Portanto, a versão máxima obrigatória de
platform
é selecionada automaticamente.
Substituir uma dependência como um módulo do Bazel
Como módulo raiz, você pode modificar as dependências do módulo do Bazel de diferentes maneiras.
Leia a seção de overrides para mais informações.
Você pode encontrar alguns exemplos de uso no repositório de exemplos.
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ê pode a introduzir usando 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 (em inglês)
Com o Bzlmod, você precisa mover a definição para um arquivo
.bzl
, que também permite compartilhar a definição entre o ESPAÇO DE TRABALHO e o 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. Ela pode ser definida no mesmo arquivo
.bzl
da macro, mas, para manter a compatibilidade com versões mais antigas do Bazel, é melhor defini-la 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 seguinte macro, que usa version
como
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, você pode 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 ESPAÇO DE TRABALHO para conseguir a versão de que precisa. 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, vamos supor 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 requer a versão de dados
2.0
, enquanto a dependênciabar
requer3.0
. A extensão de módulo emfoo
pode resolver corretamente esse conflito e selecionar automaticamente a versão3.0
para a dependência de dados.
Integrar um 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, executar lógica personalizada para resolver dependências e chamar regras de repositório para introduzir repositórios externos, essa é uma ótima maneira para os autores de regras aprimorarem os conjuntos de regras que integram gerenciadores de pacotes para linguagens específicas.
Leia a página Extensões de módulo para saber mais sobre como usá-las.
Confira uma lista dos conjuntos de regras que já adotaram o Bzlmod para buscar dependências de diferentes gerenciadores de pacotes:
Um exemplo mínimo de integração de um pseudogerenciador de pacotes está disponível no repositório de exemplos.
Detectar os conjuntos 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 de repositório no espaço de trabalho.
## WORKSPACE load("//:local_config_sh.bzl", "sh_config_rule") sh_config_rule(name = "local_config_sh")
Bzlmod (em inglês)
Com o Bzlmod, você pode introduzir o mesmo repositório usando uma extensão de módulo, o que é semelhante à introduçã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 conjuntos de ferramentas e plataformas de execução
Seguindo a última seção, depois de introduzir um repositório de informações do conjunto de ferramentas de hospedagem (por exemplo, local_config_sh
), é provável que você queira registrar o conjunto de ferramentas.
ESPAÇO DE TRABALHO
Com o WORKSPACE, você pode registrar o conjunto de ferramentas das seguintes maneiras.
É 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()
Ou registre o conjunto de ferramentas diretamente no arquivo WORKSPACE.
## 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 (em inglês)
Com o Bzlmod, as APIs
register_toolchains
eregister_execution_platforms
estão disponíveis apenas no arquivo MODULE.bazel. Não é possível chamarnative.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")
Introduzir repositórios locais
Pode ser necessário introduzir uma dependência como repositório local quando precisar de uma versão local da dependência para depuração ou se quiser incorporar um diretório no 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
enew_local_repository
.## WORKSPACE local_repository( name = "rules_java", path = "/Users/bazel_user/workspace/rules_java", )
Bzlmod (em inglês)
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 uma 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 a detecção de todas as regras de repositório nativo (consulte #18285 para ver o progresso). Em seguida, você pode chamar olocal_repository
do starlark correspondente em uma extensão de módulo. Também é útil implementar uma versão personalizada da regra de repositóriolocal_repository
se esse for um problema de bloqueio para você.
Vincular destinos
A regra bind
em WORKSPACE foi descontinuada e
não tem suporte em Bzlmod. Ele foi introduzido para fornecer um alias a um destino no
pacote //external
especial. Todos os usuários que dependem disso devem migrar.
Por exemplo, se você tiver
## WORKSPACE
bind(
name = "openssl",
actual = "@my-ssl//src:openssl-lib",
)
Isso permite que outros destinos dependam de //external:openssl
. É possível migrar isso da seguinte forma:
Substitua todos os usos de
//external:openssl
por@my-ssl//src:openssl-lib
.Ou use a regra de build
alias
Defina o seguinte destino 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-lib
.
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 de ESPAÇO DE TRABALHO, porque as dependências transitivas geralmente são carregadas com macros
*_deps
.
Inspecionar dependência externa com o arquivo resolvido do espaço de trabalho
Felizmente, a sinalização
--experimental_repository_resolved_file
pode ajudar. Essa sinalização gera essencialmente um "arquivo de bloqueio" de todas as dependências externas
buscadas no último comando do Bazel. Veja mais detalhes nesta postagem do blog.
Ele pode ser usado de duas maneiras:
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
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 de ESPAÇO DE TRABALHO, que incluem:bind
usos- Usos de
register_toolchains
eregister_execution_platforms
No entanto, se o projeto for multiplataforma, a sincronização do Bazel pode ser interrompida em determinadas plataformas, porque algumas regras de repositório podem ser executadas corretamente apenas em plataformas com suporte.
Depois de executar o comando, você terá informações sobre as dependências
externas no arquivo resolved.bzl
.
Inspecionar dependência externa com bazel query
Talvez você também saiba que 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 estar relacionada à versão de dependência externa. Portanto, tenha cuidado ao usá-la. A consulta e a inspeção de dependências externas com o Bzlmod serão conseguidas com um novo subcomando.
Dependências padrão integradas
Se você verificar o arquivo gerado por --experimental_repository_resolved_file
,
encontrará muitas dependências que não estão definidas no seu ESPAÇO DE TRABALHO.
Isso ocorre 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 exatamente a mesma sintaxe que WORKSPACE. Quando Bzlmod está ativado, se um arquivo WORKSPACE.bzlmod também existe na raiz do espaço de trabalho:
WORKSPACE.bzlmod
entra em vigor, e o conteúdo deWORKSPACE
é ignorado.- Nenhum prefixo ou sufixo foi adicionado ao arquivo WORKSPACE.bzlmod.
Usar o arquivo WORKSPACE.bzlmod pode facilitar a migração porque:
- Quando o Bzlmod é desativado, você volta a buscar dependências do arquivo de ESPAÇO DE TRABALHO original.
- Quando o Bzlmod está ativado, é possível rastrear melhor quais dependências restam para migrar com o ESPAÇO DE TRABALHO.bzlmod.
Visibilidade do repositório
O Bzlmod é capaz de controlar quais outros repositórios são visíveis em um determinado repositório. Consulte os nomes de repositórios e dependências estritos para mais detalhes.
Aqui está um resumo da visibilidade do repositório de diferentes tipos de repositórios, considerando também o ESPAÇO DE TRABALHO.
No repositório principal | Dos repositórios do módulo do Bazel | De repositórios de extensão de módulos | Dos repositórios do WORKSPACE | |
---|---|---|---|---|
O repositório principal | Visible | 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 | Visible |
Repositórios do módulo do Bazel | Dependências diretas | Dependências diretas | Dependências 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 | Dependências diretas do módulo que hospeda a extensão do módulo + todos os repositórios gerados pela mesma extensão de módulo | Dependê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 típico de migração do Bzlmod pode ter a seguinte aparência:
- Entenda quais dependências você tem no ESPAÇO DE TRABALHO.
- Adicione um arquivo MODULE.bazel vazio à raiz do projeto.
- Adicione um arquivo WORKSPACE.bzlmod vazio para substituir o conteúdo do arquivo WORKSPACE.
- Crie os destinos com o Bzlmod ativado e verifique qual repositório está ausente.
- Verifique a definição do repositório ausente no arquivo de dependência resolvido.
- Introduza a dependência ausente como um módulo do Bazel usando uma extensão de módulo ou deixe-a em WORKSPACE.bzlmod para migração posterior.
- 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 de migração do Bzlmod interativo que pode ajudar você a começar.
O script faz o seguinte:
- Gere e analise o arquivo resolvido do ESPAÇO DE TRABALHO.
- Imprimir as informações do repositório do arquivo resolvido de uma forma legível por humanos.
- Execute o comando bazel build, detecte mensagens de erro reconhecidas e recomende 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, publique-o no Bazel Central Registry.
Para fazer check-in do seu projeto no BCR, você precisa de um URL de arquivo de origem do projeto. Observe alguns detalhes ao criar o arquivo de origem:
Verifique se o arquivo aponta para uma versão específica.
O BCR só pode aceitar arquivos de origem com controle de versão porque o Bzlmod precisa conduzir a comparação de versões durante a resolução da dependência.
Verifique se o URL do arquivo está estável.
Ele verifica o conteúdo do arquivo por um valor de hash. Portanto, verifique se a soma de verificação do arquivo salvo 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 garante a soma de verificação de arquivos de origem gerados sob demanda. Em resumo, os URLs na forma de
https://github.com/<org>/<repo>/releases/download/...
são considerados estáveis, enquantohttps://github.com/<org>/<repo>/archive/...
não é. Consulte Interrupção da soma de verificação do arquivo do GitHub 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, verifique se a árvore de origem removida é um subconjunto da árvore de origem original. Isso facilita que os usuários finais substituam o módulo para uma versão sem lançamento usando
archive_override
egit_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. Ela precisa conter exemplos ou alguns testes de integração que abrangem as APIs mais comuns. Confira o 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 o módulo ao BCR com uma solicitação de envio do GitHub.
É altamente recomendável configurar o app do GitHub Publish to BCR no seu repositório para automatizar o processo de envio do módulo para o BCR.
Práticas recomendadas
Nesta seção, documentamos algumas práticas recomendadas que você precisa seguir para gerenciar melhor suas dependências externas.
Divida os destinos em pacotes diferentes para evitar a busca de dependências desnecessárias.
Confira a versão #12835 (link em inglês), em que as dependências de desenvolvimento para testes são forçadas a ser buscadas desnecessariamente para criar destinos que não precisam delas. Esse processo 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
diretivas bazel_dep
e
use_extension
para que
não sejam propagadas para projetos dependentes. Como módulo raiz, você pode usar a flag
--ignore_dev_dependency
para verificar se os destinos
ainda são criados sem dependências 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.
Relatar problemas
Consulte a lista de problemas do Bazel no GitHub (em inglês) 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.