Temas avanzados sobre dependencias externas

Informar un problema Ver fuente

Objetos que se superponen con dependencias en WORKSPACE

Siempre que sea posible, ten una sola política de versión en tu proyecto, que se requiere para las dependencias en las que compilas y terminas en tu objeto binario final. Para otros casos, puedes bloquear dependencias:

miproyecto/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. Para incluir ambos en myproject sin que se generen conflictos, asígnales 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.

Anula 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. El uso de esta marca cambia el contenido de los repositorios externos sin cambiar el 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:

  • Problemas de depuración. Por ejemplo, para anular un repositorio http_archive a un directorio local en el que puedas realizar cambios con mayor facilidad.
  • Proveedores 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 en su lugar.

Usa proxies

Bazel recopila 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 especifica).

Compatibilidad con IPv6

En máquinas que solo usan 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 llegar a direcciones externas, esto puede causar excepciones de Network unreachable y fallas de compilación. En estos casos, puedes anular el comportamiento de Bazel y preferir IPv6 con la propiedad del sistema java.net.preferIPv6Addresses=true. En particular, haz lo siguiente:

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

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

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

    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 variable de entorno COURSIER_OPTS a fin de proporcionar opciones de JVM para Coursier.

Compilaciones sin conexión

A veces, es posible que desees ejecutar una construcción sin conexión, como cuando viajas en un avión. Para casos de uso tan simples, realiza una carga 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 verdaderas compilaciones sin conexión, en las que una entidad diferente proporciona todos los archivos necesarios, Bazel admite la opción --distdir. Esta marca le indica a Bazel que busque primero en los directorios que especifica esa opción cuando una regla de repositorio le solicita a Bazel que recupere un archivo con ctx.download o ctx.download_and_extract. Cuando proporcionas una suma 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 un arranque sin conexión a partir del 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 las reglas del repositorio sin saber si llaman a la red. Por lo tanto, no puede aplicar compilaciones sin conexión por completo. Para probar si una compilación funciona correctamente sin conexión, bloquea la red de forma manual (como lo hace Bazel en su prueba de arranque).