Temas avanzados sobre dependencias externas

Dependencias de sombreado en WORKSPACE

Siempre que sea posible, ten una política de versión única en tu proyecto, que es obligatoria para las dependencias con las que compilas y que terminan en tu objeto binario final. En otros casos, puedes sombrear las 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. Inclúyelas en myproject sin conflictos dá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 --override_repository marca. El uso de esta marca cambia el contenido de los repositorios externos sin cambiar el código fuente.

Por ejemplo, para anular @foo al 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:

• Depuración de problemas (por ejemplo, para anular un repositorio http_archive a un directorio local en el que puedes realizar cambios con mayor facilidad)
• Vendoring (si estás 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)

Usa proxies

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

Compatibilidad con IPv6

En máquinas solo IPv6, Bazel puede descargar dependencias sin cambios. Sin embargo, en máquinas IPv4/IPv6 de pila doble, 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 provocar excepciones Network unreachable y fallas de compilación. En estos casos, puedes anular el comportamiento de Bazel para preferir IPv6 con la propiedad del sistema java.net.preferIPv6Addresses=true Específicamente, son las siguientes:

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

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

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

  build --jvmopt=-Djava.net.preferIPv6Addresses

• Si usas rules_jvm_external para la resolución de la versión de dependencia, también agrega -Djava.net.preferIPv6Addresses=true a la COURSIER_OPTS variable de entorno 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, recupera 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 verdaderas, 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 pide a Bazel que recupere un archivo con ctx.download o ctx.download_and_extract. Si proporcionas 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 realizar el bootstrap sin conexión desde el artefacto de distribución. Para ello, recopila todas las dependencias externas necesarias en un distdir_tar.

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