Última verificación: 21/4/2020 (historial de actualizaciones)
Punto de contacto: laurentlb
Objetivo
Nuestro objetivo es hacer que Bazel sea más extensible. Los usuarios deben poder implementar sus propias reglas con facilidad y admitir nuevos idiomas y herramientas. Queremos mejorar la experiencia de escribir y mantener esas reglas.
Nos enfocamos en dos áreas:
- Haz que el lenguaje y la API sean simples, pero potentes.
- Proporcionar mejores herramientas para leer, escribir, actualizar, depurar y probar el código
2º trimestre de 2020
Estado del proyecto y prácticas recomendadas:
- P0. No se recomienda usar macros sin nombre y asegúrate de que el nombre sea una cadena literal única. Este trabajo se enfoca 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 con respecto a las selecciones y las variables
- P1. Haz que Buildifier quite los duplicados de las listas que no ordenamos debido a los comentarios.
- P1. Se actualizó el lint de Buildifier para recomendar la incorporación de expresiones triviales.
- P2. Estudia los casos de uso de native.existing_rules y propone alternativas.
- P2. Estudiar los casos de uso del archivo de preludio y proponer alternativas
Rendimiento:
- P1. Optimiza el intérprete de Starlark con entornos planos y compilación de bytecode.
Reducción de la deuda técnica:
- P0. Se agregó la capacidad de portar símbolos nativos a Starlark debajo de @bazel_tools.
- P1. Se borraron las marcas obsoletas (algunas de las cuales 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_inputs,incompatible_new_actions_api. - P1. Asegúrate de que se puedan invertir las siguientes marcas en Bazel 4.0:
incompatible_disable_depset_items,incompatible_no_implicit_file_export,incompatible_run_shell_command_stringyincompatible_restrict_string_escapes. - P1. Termina el trabajo de lib.syntax (limpieza de la 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_pythonestá activo y la comunidad lo mantiene bien.- Asistencia continua para rules_jvm_external (sin solicitudes de extracción pendientes, clasificación de problemas ni lanzamientos).
- Mantener la infraestructura de documentación de Bazel: centralizar y canonizar los estilos de CSS en bazel-website, bazel-blog y docs
- Documentos de Bazel: Se agregaron pruebas de CI para la compilación del sitio de documentos de e2e para evitar regresiones.
1º trimestre de 2020
Estado del proyecto y prácticas recomendadas:
- Permite que los destinos hagan un seguimiento de su pila de llamadas de macro para exportarla a través de
bazel query - Implementa
--incompatible_no_implicit_file_export. - Se quitaron las APIs de depset obsoletas (#5817, #10313 y #9017).
- Se agregó un analizador de archivos cruzados en Buildifier y se implementó una verificación de funciones obsoletas.
Rendimiento:
- Haz que las pruebas basadas en Java de Bazel sean 2 veces más rápidas.
- Implementa un generador de perfiles de CPU de Starlark.
Reducción de la deuda técnica:
- Se quitaron 8 marcas incompatibles (después de invertirlas).
- Termina el trabajo de limpieza de lib.syntax (rompe las dependencias).
- Optimización de Starlark: entorno plano, compilación de bytecode
- Si es posible, borra toda la serialización de la fase de análisis.
- Crea un plan para simplificar o optimizar lib.packages
Comunidad:
- Publica un glosario que contenga definiciones de todos los términos específicos de Bazel