Para obtener documentación sobre versiones estables, usa el menú desplegable "Documentos con versiones". La vista predeterminada refleja la versión más reciente en el encabezado.

Se usó la API de Cloud Translation para traducir esta página.

Registros de Bazel

Informar un problema Ver fuente

Para descubrir dependencias, Bzlmod solicita su información de los registros de Bazel: bases de datos de módulos de Bazel. Actualmente, Bzlmod solo admite registros de índices: directorios locales o servidores HTTP estáticos que siguen un formato específico.

Registro de índices

Un registro de índices es un directorio local o un servidor HTTP estático que contiene información sobre una lista de módulos, incluida la página principal, los encargados de mantenimiento, el archivo MODULE.bazel de cada versión y la forma de recuperar la fuente de cada versión. En particular, no necesita entregar los archivos de origen.

Un registro de índices debe seguir el siguiente formato:

/bazel_registry.json: Es un archivo JSON que contiene metadatos para el registro, como los siguientes:
- mirrors: Especifica la lista de duplicados que se usarán para los archivos de origen. La URL duplicada es una concatenación de la duplicación, y la URL de origen del módulo que especifica su archivo source.json no cumple con el protocolo. Por ejemplo, si la URL de origen de un módulo es https://foo.com/bar/baz y mirrors contiene ["https://mirror1.com/", "https://example.com/mirror2/"], las URLs que Bazel probará en orden son https://mirror1.com/foo.com/bar/baz, https://example.com/mirror2/foo.com/bar/baz y, por último, la URL de origen original https://foo.com/bar/baz.
- module_base_path: Especifica la ruta base para los módulos con el tipo local_repository en el archivo source.json.
/modules: Es un directorio que contiene un subdirectorio para cada módulo de este registro.
/modules/$MODULE: Es un directorio que contiene un subdirectorio para cada versión de este módulo, así como lo siguiente:
- metadata.json: Es un archivo JSON que contiene información sobre el módulo, con los siguientes campos:
  - homepage: Es la URL de la página principal del proyecto.
  - maintainers: Es una lista de objetos JSON, cada uno de los cuales corresponde a la información de un encargado de mantenimiento del módulo en el registro. Ten en cuenta que este no es siempre el mismo que los autores del proyecto.
  - versions: Una lista de todas las versiones de este módulo que se encuentran en este registro
  - yanked_versions: Es un mapa de las versiones con extracción de este módulo. Las claves deben ser versiones en yank y los valores deben ser descripciones de por qué se movió la versión, idealmente con un vínculo para obtener más información.
/modules/$MODULE/$VERSION: Es un directorio que contiene los siguientes archivos:
- MODULE.bazel: Es el archivo MODULE.bazel de esta versión del módulo.
- source.json: Es un archivo JSON que contiene información para recuperar la fuente de esta versión del módulo.
  - El tipo predeterminado es “archive”, que representa un repositorio http_archive con los siguientes campos:
    - url: Es la URL del archivo de origen.
    - integrity: La suma de verificación de integridad del subrecurso del archivo
    - strip_prefix: Es un prefijo de directorio para quitar cuando se extrae el archivo de origen.
    - patches: Es un mapa que contiene archivos de parche para aplicar al archivo extraído. Los archivos de parche se encuentran en el directorio /modules/$MODULE/$VERSION/patches. Las claves son los nombres de los archivos de parche y los valores son la suma de verificación de integridad de estos archivos.
    - patch_strip: Igual que el argumento --strip de Unix patch.
    - archive_type: Es el tipo de archivo del archivo descargado (igual que type en http_archive). De forma predeterminada, el tipo de archivo se determina a partir de la extensión de la URL. Si el archivo no tiene extensión, puedes especificar de forma explícita una de las siguientes opciones: "zip", "jar", "war", "aar", "tar", "tar.gz", "tgz", "tar.xz", "txz", "tar.zst", "tzst", tar.bz2, "ar" o "deb".
  - Se puede cambiar el tipo para usar un repositorio de Git con estos campos:
    - type: git_repository
    - Los siguientes campos, como se describen en https://bazel.build/rules/lib/repo/git:
      - remote
      - commit
      - shallow_since
      - tag
      - init_submodules
      - verbose
      - strip_prefix
  - Se puede cambiar el tipo para usar una ruta local, que represente un repositorio local_repository, con estos campos:
    - type: local_path
    - path: Es la ruta de acceso local al repositorio, que se calcula de la siguiente manera:
      - Si path es una ruta de acceso absoluta, se mantiene igual.
      - Si path es una ruta de acceso relativa y module_base_path es una ruta absoluta, se resuelve como <module_base_path>/<path>.
      - Si path y module_base_path son rutas de acceso relativas, se resuelve como <registry_path>/<module_base_path>/<path>. El registro debe estar alojado de forma local y --registry=file://<registry_path> lo debe usar. De lo contrario, Bazel arrojará un error
- patches/: Es un directorio opcional que contiene archivos de parche, que solo se usa cuando source.json tiene el tipo "archive".

Registro central de Bazel

El registro central de Bazel (BCR) en https://bcr.bazel.build/ es un registro de índices con contenido respaldado por el repositorio de GitHub bazelbuild/bazel-central-registry. Puedes explorar el contenido con el frontend web en https://registry.bazel.build/.

La comunidad de Bazel mantiene el BCR, y los colaboradores pueden enviar solicitudes de extracción. Consulta los lineamientos de contribución a BCR.

Además de seguir el formato de un registro de índices normal, BCR requiere un archivo presubmit.yml para cada versión del módulo (/modules/$MODULE/$VERSION/presubmit.yml). En este archivo, se especifican algunos objetivos esenciales de compilación y prueba que puedes usar para verificar la validez de esta versión del módulo. Las canalizaciones de CI de BCR también usan esto para garantizar la interoperabilidad entre módulos.

Selecciona registros

Se puede usar la marca repetible --registry de Bazel para especificar la lista de registros a los que solicitar módulos, de modo que puedas configurar tu proyecto para recuperar dependencias de un registro interno o de terceros. Los registros anteriores tienen prioridad. Para mayor comodidad, puedes incluir una lista de marcas --registry en el archivo .bazelrc de tu proyecto.

Si tu registro está alojado en GitHub (por ejemplo, como una bifurcación de bazelbuild/bazel-central-registry), tu valor --registry necesita una dirección de GitHub sin procesar en raw.githubusercontent.com. Por ejemplo, en la rama main de la bifurcación my-org, deberías establecer --registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/.

El uso de la marca --registry evita que se use el registro central de Bazel de forma predeterminada, pero puedes volver a agregarlo agregando --registry=https://bcr.bazel.build.