Temas avanzados sobre dependencias externas

Informar un problema Ver fuente . Por la noche · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Objetos que se superponen con dependencias en WORKSPACE

Nota: Esta sección se aplica a WORKSPACE solo para el sistema. Para Bzlmod, usa una versión múltiple anulación.

Cuando sea posible, implementa una sola política de versiones en tu proyecto, necesarias para las dependencias con las que compilas y terminas en tu binario. 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 llamamos 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 el --override_repository marca. El uso de esta marca cambia el contenido de los repositorios externos sin sin modificar tu código fuente.

Por ejemplo, para anular @foo en el directorio local /path/to/local/foo, usa este código: 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 de http_archive en un directorio local, en el que se pueden realizar cambios con mayor facilidad.
• Proveedores Si estás en un entorno en el que no puedes hacer llamadas de red anular las reglas de repositorio basadas en la red para que apunten a directorios locales en su lugar.

Nota: Con Bzlmod, recuerda usar el repositorio canónico aquí. Como alternativa, usa el --override_module marca para anular un módulo en un directorio local, similar a Directiva local_path_override en MODULE.bazel.

Usa proxies

Bazel recoge direcciones de proxy de HTTPS_PROXY y HTTP_PROXY. variables de entorno y las usa para descargar archivos HTTP y HTTPS (si especificada).

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, preferir IPv4 si está habilitado. En algunos casos, por ejemplo, cuando la conexión IPv4 la red no puede resolver ni alcanzar direcciones externas, lo que puede causar excepciones de Network unreachable y fallas de compilación. En estos casos, puedes anular el comportamiento de Bazel de preferir IPv6 con el Sistema java.net.preferIPv6Addresses=true propiedad. En particular, haz lo siguiente:

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

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

• Cuando se ejecutan destinos de compilación de Java que necesitan conectarse a Internet (como como para las pruebas de integración), usa el --jvmopt=-Djava.net.preferIPv6Addresses=true herramienta marca. 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, agrega -Djava.net.preferIPv6Addresses=true al entorno COURSIER_OPTS para proporcionar opciones de JVM para Coursier.

Compilaciones sin conexión

Es posible que desees ejecutar una construcción sin conexión; por ejemplo, cuando viajas en una de 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 primero investigue los directorios que especifica esa opción cuando una regla de repositorio pide a Bazel que Recupera un archivo con ctx.download. ctx.download_and_extract De proporcionando una suma hash del archivo necesario, Bazel busca un archivo que coincida con nombre base de la primera URL y utiliza la copia local si el hash coincide.

Bazel usa esta técnica para realizar un arranque sin conexión desde la distribución artefacto. Para ello, recopila todos los recursos dependencias en un entorno distdir_tar

Bazel permite la ejecución de comandos arbitrarios en las reglas del repositorio sin saberlo. si llaman a la red y, por lo tanto, no pueden aplicar compilaciones completamente sin conexión. Para probar si una compilación funciona correctamente sin conexión, bloquear la red manualmente (como lo hace en su arranque prueba).