Temas avanzados sobre dependencias externas

Cómo ocultar dependencias en WORKSPACE

Siempre que sea posible, ten una sola política de versiones en tu proyecto, que es obligatoria para las dependencias con las que compilas y que terminan en tu archivo binario final. En otros casos, puedes ocultar dependencias:

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 = "..."
)

Ambas dependencias, A y B, dependen de diferentes versiones de testrunner. Incluye ambos en myproject sin conflictos asignándoles nombres distintos en 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"}
)

También puedes usar este mecanismo para unir diamantes. Por ejemplo, si A y B tienen la misma dependencia, pero la llaman con nombres diferentes, une esas dependencias en myproject/WORKSPACE.

Cómo anular repositorios desde la línea de comandos

Para anular un repositorio declarado con un repositorio local desde la línea de comandos, usa la marca --override_repository. Usar esta marca cambia el contenido de los repositorios externos sin cambiar tu código fuente.

Por ejemplo, para anular @foo en el directorio local /path/to/local/foo, pasa la marca --override_repository=foo=/path/to/local/foo.

En los casos de uso, se incluye lo siguiente:

• Depurar problemas Por ejemplo, para anular un repositorio http_archive y usar un directorio local en el que puedas realizar cambios con mayor facilidad.
• Vendoring Si te encuentras en un entorno en el que no puedes realizar llamadas de red, anula las reglas del repositorio basadas en la red para que apunten a directorios locales.

Uso de proxies

Bazel toma las direcciones de proxy de las variables de entorno HTTPS_PROXY y HTTP_PROXY, y las usa para descargar los archivos HTTP y HTTPS (si se especifican).

Compatibilidad con IPv6

En las máquinas solo IPv6, Bazel puede descargar dependencias sin cambios. Sin embargo, en las máquinas de pila doble IPv4/IPv6, Bazel sigue la misma convención que Java y prefiere IPv4 si está habilitado. En algunas situaciones, por ejemplo, cuando la red IPv4 no puede resolver o alcanzar direcciones externas, esto puede causar excepciones de Network unreachable y fallas en la compilación. En estos casos, puedes anular el comportamiento de Bazel para que prefiera IPv6 con la propiedad del sistema java.net.preferIPv6Addresses=true. En particular, haz lo siguiente:

• Usa la --host_jvm_args=-Djava.net.preferIPv6Addresses=true opción de inicio, por ejemplo, agregando la siguiente línea en tu archivo .bazelrc:

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

• Cuando ejecutes destinos de compilación de Java que necesiten conectarse a Internet (como para pruebas de integración), usa la marca de herramienta --jvmopt=-Djava.net.preferIPv6Addresses=true. Por ejemplo, incluye lo siguiente en tu archivo.bazelrc:

  build --jvmopt=-Djava.net.preferIPv6Addresses

• Si usas rules_jvm_external para la resolución de versiones de dependencias, también agrega -Djava.net.preferIPv6Addresses=true a la variable de entorno COURSIER_OPTS para proporcionar opciones de JVM para Coursier.

Compilaciones sin conexión

A veces, es posible que desees ejecutar una compilación sin conexión, por ejemplo, cuando viajas en avión. Para casos de uso tan simples, realiza una recuperación previa de los repositorios necesarios con bazel fetch o bazel sync. Para inhabilitar la recuperación de más repositorios durante la compilación, usa la opción --nofetch.

Para las compilaciones sin conexión reales, en las que una entidad diferente proporciona todos los archivos necesarios, Bazel admite la opción --distdir. Esta marca le indica a Bazel que primero busque en los directorios especificados por esa opción cuando una regla de repositorio le solicite a Bazel que recupere un archivo con ctx.download o ctx.download_and_extract. Cuando se proporciona una suma de hash del archivo necesario, Bazel busca un archivo que coincida con el nombre base de la primera URL y usa la copia local si el hash coincide.

Bazel usa esta técnica para el bootstrapping sin conexión desde el artefacto de distribución. Para ello, recopila todas las dependencias externas necesarias en un distdir_tar interno.

Bazel permite la ejecución de comandos arbitrarios en reglas de repositorio sin saber si llaman a la red, por lo que no puede aplicar compilaciones completamente sin conexión. Para probar si una compilación funciona correctamente sin conexión, bloquea manualmente la red (como lo hace Bazel en su prueba de bootstrap).