Bazel admite dependencias externas, archivos de origen (de texto y binarios) usados de tu compilación que no sean de tu lugar de trabajo. Por ejemplo, podrían ser una de reglas alojadas en un repositorio de GitHub, un artefacto de Maven o un directorio en tu fuera de tu espacio de trabajo actual.
A partir de Bazel 6.0, hay dos formas de administrar dependencias externas con Bazel:
el sistema WORKSPACE tradicional y centrado en el repositorio.
el nuevo sistema MODULE.bazel centrado en el módulo (con nombre interno Bzlmod,
y habilitado con la marca --enable_bzlmod). Ambos sistemas se pueden usar
pero Bzlmod reemplazará el sistema WORKSPACE en el futuro de Bazel
consulta la guía de migración de Bzlmod para saber cómo
migrar.
En este documento, se explican los conceptos en torno a la administración de dependencias externas. en Bazel, antes de entrar en más detalles sobre los dos sistemas en orden.
Conceptos
Repositorio
Un directorio con un archivo WORKSPACE o WORKSPACE.bazel, que contenga el código fuente
archivos que se usarán en una compilación de Bazel. A menudo se abrevia como repo.
Repositorio principal
El repositorio en el que se ejecuta el comando de Bazel actual.
Lugar de trabajo
El entorno que comparten todos los comandos de Bazel se ejecuta en el mismo repositorio principal.
Históricamente, los conceptos de “repositorio” y “espacio de trabajo” han sido combinadas; el término “espacio de trabajo” se suele usar para referirse a los principales repositorio y, a veces, incluso se usa como sinónimo de "repositorio".
Nombre del repositorio canónico
El nombre canónico con el que se puede acceder a un repositorio. En el contexto de un
cada repositorio tiene un solo nombre canónico. Un destino dentro de un repositorio
cuyo nombre canónico es canonical_name se puede resolver mediante la etiqueta
@@canonical_name//pac/kage:target (ten en cuenta el @ doble).
El repositorio principal siempre tiene la cadena vacía como nombre canónico.
Nombre aparente del repositorio
El nombre con el que se puede acceder a un repositorio en el contexto de otro repositorio específico.
Esto puede considerarse como el "sobrenombre" del repositorio: el repo con nombre canónico
michael podría tener el nombre aparente mike en el contexto del repositorio
alice, pero puede tener el nombre aparente mickey en el contexto del repositorio
bob En este caso, la etiqueta puede abordar un objetivo dentro de michael.
@mike//pac/kage:target en el contexto de alice (ten en cuenta el único @).
Por el contrario, esto se puede entender como una asignación de repositorio: cada repositorio mantiene una asignación del "nombre aparente del repo" a un "nombre del repositorio canónico".
Regla del repositorio
Un esquema para las definiciones de repositorios que le indica a Bazel cómo materializar una
en un repositorio de confianza. Por ejemplo, podría ser "descarga un archivo ZIP de una URL determinada
“extraer” o “obtener un determinado artefacto de Maven y hacer que esté disponible como
java_import target” o “symlink un directorio local”. Todos los repo
definida llamando a una regla de repositorio con una cantidad apropiada de argumentos.
Consulta Reglas del repositorio para obtener más información sobre cómo escribir. las reglas de tu repositorio.
Sin duda, las reglas de repo más comunes son
http_archive, que descarga un archivo
de una URL y la extrae.
local_repository, que vincula un symlink a
que ya es un repositorio de Bazel.
Recupera un repositorio
La acción de hacer que un repositorio esté disponible en el disco local ejecutando su repo. Los repositorios definidos en un lugar de trabajo no están disponibles en el disco local. antes de que se recuperen.
Por lo general, Bazel solo recupera un repo cuando necesita algo del repo. y aún no se recuperó el repo. Si ya se recuperó el repo anteriormente, Bazel solo lo vuelve a recuperar si su definición cambió.
Diseño de directorio
Después de que se recupere, podrás encontrar el repositorio en el subdirectorio external, en el
base de salida, debajo de su nombre canónico.
Puedes ejecutar el siguiente comando para ver el contenido del repo con el
nombre canónico canonical_name:
ls $(bazel info output_base)/external/ canonical_name
Cómo administrar dependencias externas con Bzlmod
Bzlmod, el nuevo subsistema de dependencia externa, no funciona directamente con repo. definiciones En su lugar, compila un gráfico de dependencia a partir de módulos, ejecuta extensions en la parte superior del gráfico y define los repositorios según corresponda.
Un módulo de Bazel es un proyecto de Bazel que puede tener varios
y cada una publica metadatos sobre otros módulos de los que depende
. Un módulo debe tener un archivo MODULE.bazel en la raíz del repositorio, junto al
archivo WORKSPACE. Este archivo es el manifiesto del módulo, que declara su nombre
la versión y la lista de dependencias, entre otros datos. La siguiente es una
ejemplo:
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
Un módulo solo debe enumerar sus dependencias directas, que Bzlmod busca en un
Registro de Bazel: De forma predeterminada, se llama Bazel Central
Registro. El registro proporciona la
de las dependencias MODULE.bazel, que permiten que Bazel descubra toda la
gráfico de dependencia transitivo antes de realizar la resolución de la versión.
Después de la resolución de versión, en la que se selecciona una versión para cada módulo,
Bazel vuelve a consultar el registro para aprender a definir un repositorio para cada módulo.
(en la mayoría de los casos, mediante http_archive).
Los módulos también pueden especificar datos personalizados llamados etiquetas, que se consumidas por las extensiones del módulo después de la resolución del módulo para definir repositorios adicionales. Estas extensiones tienen funciones similares a las de repo. reglas de firewall, lo que les permite realizar acciones como E/S de archivos y enviar solicitudes. Entre otras cosas, permiten que Bazel interactúe con otros paquetes de los sistemas de administración, a la vez que respeta el gráfico de dependencias creado a partir de Bazel módulos.
Vínculos externos en Bzlmod
- Ejemplos de uso de bzlmod en bazelbuild/ejemplos
- Renovación de las dependencias externas de Bazel (documento original de diseño de Bzlmod)
- Charla de BazelCon 2021 en Bzlmod
- Charla del Día de la Comunidad de Bazel en Bzlmod
Define repositorios con WORKSPACE
Históricamente, se pueden administrar dependencias externas definiendo repositorios en el
Archivo WORKSPACE (o WORKSPACE.bazel). Este archivo tiene una sintaxis similar a
BUILD y emplean reglas de repositorio en lugar de reglas de compilación.
El siguiente fragmento es un ejemplo de cómo usar la regla del repositorio http_archive en el
Archivo WORKSPACE:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "foo",
urls = ["https://example.com/foo.zip"],
sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)
El fragmento define un repositorio cuyo nombre canónico es foo. En WORKSPACE
de forma predeterminada, el nombre canónico de un repositorio también es su nombre aparente
para todos los demás repos.
Consulta la lista completa de funciones disponibles en
WORKSPACE.
Deficiencias del sistema de WORKSPACE
Durante los años desde que se introdujo el sistema WORKSPACE, los usuarios informaron
muchas dificultades, como las siguientes:
- Bazel no evalúa los archivos
WORKSPACEde ninguna dependencia, por lo que las dependencias transitivas deben definirse en el archivoWORKSPACEde la instancia repo, además de las dependencias directas. - Para solucionar esto, los proyectos adoptaron el estándar "deps.bzl" en el que
definen una macro que, a su vez, define varios repositorios y les piden a los usuarios
llamarán a esta macro en sus archivos
WORKSPACE.- Esto tiene sus propios problemas: las macros no pueden
loadotros archivos.bzl, por lo que estos proyectos tienen que definir sus dependencias transitivas en este “deps” o haz que el usuario llame a varias “deps” en capas o usar las macros. - Bazel evalúa el archivo
WORKSPACEde forma secuencial. Además: las dependencias se especifican mediantehttp_archivecon URLs, sin ninguna información de la versión. Esto significa que no hay una forma confiable de realizar resolución de la versión en el caso de dependencias de diamante (Adepende deByC;ByCdependen de diferentes versiones deD).
- Esto tiene sus propios problemas: las macros no pueden
Debido a las deficiencias de WORKSPACE, Bzlmod reemplazará la versión heredada WORKSPACE en versiones futuras de Bazel. Lee el artículo sobre la migración a Bzlmod sobre cómo migrar a Bzlmod.