Ú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 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 enfocamos en dos áreas:
- Haz que el lenguaje y la API sean simples pero potentes.
- Proporciona mejores herramientas para leer, escribir, actualizar, depurar y probar el código.
2º trimestre de 2020
Estado del desarrollo y prácticas recomendadas:
- P0. Disuade las macros sin tener un nombre y asegúrese de que este sea un literal de string único. Este trabajo se enfoca 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 con respecto a las selecciones y las variables.
- P1. Se hizo que el compilador quite los duplicados de las listas que no se ordenan debido a los comentarios.
- P1. Se actualizó linter del compilador para recomendar la intercalación de expresiones triviales.
- P2. Estudia casos de uso de native.Existing_rules y propone alternativas.
- P2. Estudia casos de uso para el archivo de preludio y propone alternativas.
Rendimiento:
- P1. Optimizar el intérprete de Starlark mediante entornos planos y compilación de código 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 cambiar 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 la API, separación de Bazel).
- P2. Se redujo 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 bien mantenido por la comunidad.- Asistencia continua para rules_jvm_external (sin solicitudes de extracción pendientes, clasificación de problemas ni 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 de documentos de e2e a fin de evitar regresiones.
1º trimestre de 2020
Estado del desarrollo y prácticas recomendadas:
- Permitir que los objetivos hagan un seguimiento de su pila de llamadas de macros para exportar mediante
bazel query - Implementa
--incompatible_no_implicit_file_export. - Se quitaron las APIs de depset obsoletas (#5817, #10313, #9017).
- Se agregó un analizador de archivos cruzados en Buildifier y, además, implementa una verificación para funciones obsoletas.
Rendimiento:
- Logra 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:
- Quita 8 marcas incompatibles (después de girarlas).
- Finaliza el trabajo de limpieza de lib.syntax (romper las dependencias).
- Optimización de Starlark: entorno plano, compilación de código de bytes
- Si es posible, borra toda la serialización de la fase de análisis
- Planificar para simplificar u optimizar lib.packages
Comunidad:
- Publicar un glosario que contenga las definiciones de todos los términos específicos de Bazel