Última verificación: 21 de abril de 2020 (historial de actualizaciones)
Punto de contacto: laurentlb
Objetivo
Nuestro objetivo es que Bazel sea más extensible. Los usuarios deben poder implementar con facilidad sus propias reglas y admitir lenguajes y herramientas nuevos. Queremos mejorar la experiencia de escritura y mantenimiento de esas reglas.
Nos concentramos en dos áreas:
- Haz que el lenguaje y la API sean simples pero potentes.
- Proporcionan mejores herramientas para leer, escribir, actualizar, depurar y probar el código.
2º trimestre de 2020
Estado de compilación y prácticas recomendadas:
- P0 Para disuadir a las macros sin nombre, asegúrate de que 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 Haz que los comandos de Buildozer sean confiables en relación con las selecciones y las variables.
- P1. Hace que Buildifier quite los duplicados de las listas que no ordenamos debido a los comentarios.
- P1. Actualiza el linter de Buildifier para recomendar la intercalación de expresiones triviales.
- P2. Estudia casos de uso de native.existing_rules y propone alternativas.
- P2. Estudia casos prácticos para el archivo preludio y propone alternativas.
Rendimiento:
- P1. Optimiza el intérprete de Starlark mediante entornos planos y compilación de códigos de bytes.
Reducción de la deuda técnica:
- P0 Agrega la capacidad de portar símbolos nativos a Starlark debajo de @bazel_tools.
- P1. Borra las marcas obsoletas (algunas todavía 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 las siguientes marcas se puedan girar en Bazel 4.0:
incompatible_disable_depset_items,incompatible_no_implicit_file_export,incompatible_run_shell_command_string,incompatible_restrict_string_escapes. - P1. Termina 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 para los paquetes de Java de Bazel.
Comunidad:
rules_pythonestá activo y la comunidad lo mantiene bien.- Compatibilidad continua con rules_jvm_external (sin solicitudes de extracción pendientes, prioridad de problemas, creación de actualizaciones)
- Mantener la infraestructura de documentación de Bazel: centralizar y canonicalizar los estilos de CSS en bazel-website, bazel-blog, docs
- Documentos de Bazel: agrega pruebas de CI para la compilación de sitios de documentos e2e a fin de evitar regresiones.
1º trimestre de 2020
Estado de compilación y prácticas recomendadas:
- Permitir que los destinos hagan un seguimiento de su pila de llamadas de macros para exportar mediante
bazel query - Implementa
--incompatible_no_implicit_file_export. - Se quitaron las API depset obsoletas (#5817, #10313, #9017).
- Agrega un analizador de archivos cruzados en Buildifier y, luego, implementa una verificación para las funciones obsoletas.
Rendimiento:
- Las pruebas basadas en Java de Bazel se duplicaron.
- Implementar un generador de perfiles de CPU de Starlark
Reducción de la deuda técnica:
- Quita 8 marcas incompatibles (después de darlas vuelta).
- Termina el trabajo de limpieza de lib.syntax (rompe dependencias).
- Optimización de Starlark: entorno plano, compilación de códigos de bytes
- Si es posible, borra toda la serialización de la fase de análisis.
- Haz un plan para simplificar o optimizar paquetes lib.package.
Comunidad:
- Publicar un glosario que contenga las definiciones de todos los términos específicos de Bazel