Última verificación: 21 de abril de 2020 (historial de actualizaciones)
Punto de contacto: laurentlb
Objetivo
Nuestro objetivo es hacer que Bazel sea más extensible. Los usuarios deberían poder implementar fácilmente sus propias reglas y admitir nuevos lenguajes y herramientas. Queremos mejorar la experiencia de escritura y mantenimiento de esas reglas.
Nos enfocamos en dos áreas:
- Haz que el lenguaje y la API sean simples y, a la vez, potentes.
- Proporcionar mejores herramientas para leer, escribir, actualizar, depurar y probar el código
2º trimestre de 2020
Estado de la compilación y prácticas recomendadas:
- P0. Desalienta las macros que no tengan nombre y asegúrate de que el nombre sea un literal de string único. Este trabajo se centra en la base de código de Google, pero puede afectar las herramientas disponibles de forma pública.
- P0. Hacer que los comandos de Buildozer sean confiables en cuanto a las selecciones y las variables.
- P1: Hacer que Buildifier quite los duplicados de las listas que no ordenamos debido a los comentarios.
- P1: Se actualizó el linter de Buildifier para recomendar la incorporación de expresiones triviales.
- P2: Estudia los casos de uso de native.Existing_rules y propone alternativas.
- P2: Estudia los casos de uso para el archivo de introducción y propone alternativas.
Rendimiento:
- P1: Optimiza el intérprete de Starlark con entornos planos y compilación de código de bytes.
Reducción de la deuda técnica:
- P0. Se agregó la capacidad de portar símbolos nativos a Starlark debajo de @bazel_tools.
- P1: Borra marcas obsoletas (algunas de ellas aún se usan en Google, por lo que primero debemos limpiar la base de código):
incompatible_always_check_depset_elements,incompatible_disable_deprecated_attr_params,incompatible_no_support_tools_in_action_inputsyincompatible_new_actions_api. - P1: Asegúrate de que las siguientes marcas se puedan activar en Bazel 4.0:
incompatible_disable_depset_items,incompatible_no_implicit_file_export,incompatible_run_shell_command_stringyincompatible_restrict_string_escapes. - P1: Finaliza el trabajo de lib.syntax (limpieza de API, separación de Bazel).
- P2: Reduce en un 50% la latencia de compilación y prueba de una edición trivial en los paquetes de Java de Bazel.
Comunidad:
rules_pythones una comunidad activa y bien mantenida.- Compatibilidad continua para rules_jvm_external (sin solicitudes de extracción pendientes, clasificación de problemas, lanzamiento de versiones)
- Mantener la infraestructura de documentación de Bazel: centralizar y canonicalizar los estilos de CSS en bazel-website, bazel-blog y documentos
- Documentos de Bazel: Agrega pruebas de CI para la compilación del sitio del documento e2e para evitar regresiones.
1º trimestre de 2020
Estado de la compilación y prácticas recomendadas:
- Permitir que los destinos hagan un seguimiento de su pila de llamadas de macros para la exportación mediante
bazel query - Implementa
--incompatible_no_implicit_file_export. - Se quitaron las APIs de depósito obsoletas (#5817, #10313, #9017).
- Agrega un analizador de archivos cruzados en Buildifier e implementa una verificación para las funciones obsoletas.
Rendimiento:
- Haz que las pruebas de Bazel basadas en Java sean 2 veces más rápidas.
- Implementar un generador de perfiles de CPU de Starlark
Reducción de la deuda técnica:
- Quita 8 marcas incompatibles (después de girarlas).
- Finaliza el trabajo de limpieza de lib.syntax (se interrumpe las dependencias).
- Optimización de Starlark: entorno plano y compilación de códigos de bytes
- Borrar toda la serialización de la fase de análisis, si es posible
- Crea un plan para simplificar/optimizar lib.packages
Comunidad:
- Publicar un glosario con las definiciones de todos los términos específicos de Bazel