Ú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 sus propias reglas y admitir nuevos lenguajes y herramientas. Queremos y mejoran 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. Desalentar las macros que no tengan nombre y asegurarse de que el nombre sea único literal de cadena. Este trabajo se enfoca en la base de código de Google, pero puede afectar disponibles para el público.
- P0. Hacer que los comandos de Buildozer sean confiables en cuanto a las selecciones y las variables.
- P1: Hacer que Buildifier elimine los duplicados de las listas que no ordenamos. 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 código de bytes compilación.
Reducción de la deuda técnica:
- P0. Se agregó la capacidad de portar símbolos nativos a Starlark debajo de @bazel_tools.
- P1: Borrar marcas obsoletas (algunas de ellas aún se usan en Google, por lo que debemos
primero limpia 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 puedan girarse en Bazel 4.0:
incompatible_disable_depset_items,incompatible_no_implicit_file_export,incompatible_run_shell_command_string,incompatible_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, problemas y hacer lanzamientos).
- Mantener la infraestructura de documentación de Bazel: centralizar y canonicalizar CSS estilos en bazel-website, bazel-blog, docs
- 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).
- Se agregó un analizador de archivos cruzados en Buildifier y se implementa una verificación para los elementos obsoletos. funciones.
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