Tópicos avançados sobre dependências externas

Informar um problema Ver código-fonte Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Dependências de sombra no WORKSPACE

Sempre que possível, tenha uma política de versão única no projeto, que é necessária para dependências que você compila e que acabam no binário final. Para outros casos, você pode simular dependências:

myproject/WORKSPACE

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/WORKSPACE

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

B/WORKSPACE 

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

As dependências A e B dependem de versões diferentes de testrunner. Inclua os dois em myproject sem conflito, nomes distintos em myproject/WORKSPACE:

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

Você também pode usar esse mecanismo para unir diamantes. Por exemplo, se A e B tiverem a mesma dependência, mas com nomes diferentes, una essas dependências em myproject/WORKSPACE.

Como substituir repositórios na linha de comando

Para substituir um repositório declarado por um repositório local na linha de comando, use a flag --override_repository. O uso dessa flag muda o conteúdo de repositórios externos sem mudar o código-fonte.

Por exemplo, para substituir @foo pelo diretório local /path/to/local/foo, transmita a flag --override_repository=foo=/path/to/local/foo.

Os casos de uso incluem o seguinte:

  • Depurar problemas. Por exemplo, para substituir um repositório http_archive por um diretório local em que você possa fazer alterações com mais facilidade.
  • Disponibilização de pacotes de terceiros. Se você estiver em um ambiente em que não é possível fazer chamadas de rede, substitua as regras de repositório baseadas em rede para apontar para diretórios locais.

Como usar proxies

O Bazel extrai endereços de proxy das variáveis de ambiente HTTPS_PROXY e HTTP_PROXY e os usa para fazer o download de arquivos HTTP e HTTPS (se especificado).

Suporte a IPv6

Em máquinas somente IPv6, o Bazel pode fazer o download de dependências sem mudanças. No entanto, em máquinas IPv4/IPv6 de pilha dupla, o Bazel segue a mesma convenção do Java, preferindo o IPv4 se ele estiver ativado. Em algumas situações, por exemplo, quando a rede IPv4 não consegue resolver/acessar endereços externos, isso pode causar exceções Network unreachable e falhas de build. Nesses casos, é possível substituir o comportamento do Bazel para preferir o IPv6 usando a propriedade do sistema java.net.preferIPv6Addresses=true. Especificamente:

  • Use a opção de inicialização --host_jvm_args=-Djava.net.preferIPv6Addresses=true, por exemplo, adicionando a seguinte linha ao arquivo .bazelrc:

    startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

  • Ao executar destinos de build Java que precisam se conectar à Internet (como para testes de integração), use a flag de ferramenta --jvmopt=-Djava.net.preferIPv6Addresses=true. Por exemplo, inclua no arquivo .bazelrc:

    build --jvmopt=-Djava.net.preferIPv6Addresses

  • Se você estiver usando rules_jvm_external para resolução de versão de dependência, adicione também -Djava.net.preferIPv6Addresses=true à variável de ambiente COURSIER_OPTS para fornecer opções de JVM para Coursier.

Builds off-line

Às vezes, você pode querer executar um build off-line, por exemplo, quando estiver viajando de avião. Para casos de uso simples, faça o precarregamento dos repositórios necessários com bazel fetch ou bazel sync. Para desativar a busca de outros repositórios durante o build, use a opção --nofetch.

Para builds totalmente off-line, em que uma entidade diferente fornece todos os arquivos necessários, o Bazel oferece suporte à opção --distdir. Essa flag instrui o Bazel a procurar primeiro nos diretórios especificados por essa opção quando uma regra de repositório pede que o Bazel busque um arquivo com ctx.download ou ctx.download_and_extract. Ao fornecer uma soma de hash do arquivo necessário, o Bazel procura um arquivo que corresponda ao nome básico do primeiro URL e usa a cópia local se o hash corresponder.

O próprio Bazel usa essa técnica para inicializar off-line usando o artefato de distribuição. Isso é feito coletando todas as dependências externas necessárias em um distdir_tar interno.

O Bazel permite a execução de comandos arbitrários nas regras do repositório sem saber se eles chamam a rede, e, portanto, não pode aplicar builds totalmente off-line. Para testar se um build funciona corretamente off-line, bloqueie manualmente a rede (como o Bazel faz no teste de inicialização).