Temas avanzados sobre dependencias externas

Informar un problema Ver fuente Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Oculta las dependencias en WORKSPACE

Nota: Esta sección solo se aplica al sistema WORKSPACE. Para Bzlmod, usa una anulación de varias versiones.

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 binario final. En otros casos, puedes crear sombras de 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. Para incluir ambos en myproject sin 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.

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. 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 en un directorio local en el que puedes 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.

Nota: Con Bzlmod, recuerda usar nombres de repositorios canónicos aquí. Como alternativa, usa la marca --override_module para anular un módulo en un directorio local, de manera similar a la directiva local_path_override en MODULE.bazel.

Usa proxies

Bazel toma las direcciones de proxy de las variables de entorno HTTPS_PROXY y HTTP_PROXY 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 generar excepciones de 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. 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 deban conectarse a Internet (como en las 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 Courseier.

Compilaciones sin conexión

A veces, es posible que desees ejecutar una compilación sin conexión, por ejemplo, cuando viajas en un avión. Para casos de uso tan simples, precarga 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 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 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 de base de la primera URL y usa la copia local si el hash coincide.

Bazel usa esta técnica para iniciar 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 las reglas del repositorio sin saber si se llaman a la red, por lo que no se pueden aplicar compilaciones completamente sin conexión. 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 inicio).