Ú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
Compilación de prácticas recomendadas y de salud:
- P0. Desalienta el uso de macros sin nombre y asegúrate de que el nombre sea un literal de cadena único. Este trabajo se centra en la base de código de Google, pero puede afectar las herramientas disponibles públicamente.
- P0. Haz que los comandos de Buildozer sean confiables en relación con las selecciones y las variables.
- P1. Haz que Buildifier quite los duplicados en las listas que no ordenamos debido a los comentarios.
- P1. Se actualizó el verificador de Buildifier para recomendar la inserción de expresiones triviales.
- P2. Estudiar los casos de uso de native.existing_rules y proponer alternativas
- P2. Estudiar los casos de uso del archivo de avance y proponer 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 transferir símbolos nativos a Starlark en @bazel_tools.
- P1. Borra las 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_string,incompatible_restrict_string_escapes. - P1. Finalizar el trabajo de lib.syntax (limpieza de la API, separación de Bazel)
- P2. Reducir 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á activa y la comunidad la mantiene en buen estado.- Asistencia continua para rules_jvm_external (sin solicitudes de extracción pendientes, clasificación de problemas y lanzamientos).
- Mantener la infraestructura de documentación de Bazel: centralizar y canonizar los estilos CSS en bazel-website, bazel-blog y docs
- Documentos de Bazel: Se agregaron pruebas de CI para la compilación del sitio de documentación de E2E para evitar regresiones.
1º trimestre de 2020
Compilación de prácticas recomendadas y de salud:
- Permite que los objetivos hagan un seguimiento de su pila de llamadas de macros para exportar a través de
bazel query - Implementa
--incompatible_no_implicit_file_export. - Se quitaron las APIs de depset obsoletas (números 5817, 10313 y 9017).
- Se agregó un analizador de archivos cruzados en Buildifier y se implementó una verificación para las funciones obsoletas.
Rendimiento:
- Las pruebas basadas en Java de Bazel son 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).
- Finaliza el trabajo de limpieza de lib.syntax (rompe dependencias).
- Optimización de Starlark: entorno plano y compilación de bytecode
- Borra toda la serialización de la fase de análisis, si es posible.
- Crea un plan para simplificar o optimizar lib.packages
Comunidad:
- Publicar un glosario que contenga definiciones de todos los términos específicos de Bazel