Última verificación: 2020-04-21 (historial de actualizaciones)
Punto de contacto: laurentlb
Objetivo
Nuestro objetivo es hacer que Bazel sea más extensible. Los usuarios deberían poder implementar fácilmente sus propias reglas y admitir nuevas herramientas y lenguajes. Queremos mejorar la experiencia de escribir y mantener esas reglas.
Nos enfocamos en dos áreas:
- Hacer 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 de la compilación y prácticas recomendadas:
- P0. Desalentar las macros sin nombre y asegurarse 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. Hacer que los comandos de Buildozer sean confiables con respecto a las selecciones y las variables.
- P1. Hacer que Buildifier quite los duplicados de las listas que no ordenamos debido a los comentarios.
- P1. Actualizar el linter de Buildifier para recomendar la incorporació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 preludio y proponer alternativas.
Rendimiento:
- P1. Optimizar el intérprete de Starlark con entornos planos y compilación de bytecode.
Reducción de la deuda técnica:
- P0. Agregar la capacidad de transferir símbolos nativos a Starlark debajo de @bazel_tools.
- P1. Borrar 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_inputs,incompatible_new_actions_api. - P1. Asegurarse de que las siguientes marcas se puedan invertir 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 de los paquetes Java de Bazel.
Comunidad:
- La comunidad mantiene y actualiza
rules_pythonde forma activa. - Compatibilidad continua con 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: agregar pruebas de CI para la compilación del sitio de documentación de extremo a extremo para evitar regresiones.
1º trimestre de 2020
Estado de la compilación y prácticas recomendadas:
- Permitir que los destinos realicen un seguimiento de su pila de llamadas de macros para exportar a través de
bazel query - Implementar
--incompatible_no_implicit_file_export - Quitar las APIs de depset obsoletas (#5817, #10313, #9017).
- Agregar un analizador de archivos cruzados en Buildifier e implementar una verificación de funciones obsoletas.
Rendimiento:
- Hacer que las pruebas basadas en Java de Bazel sean 2 veces más rápidas.
- Implementar un generador de perfiles de CPU de Starlark.
Reducción de la deuda técnica:
- Quitar 8 marcas incompatibles (después de invertirlas).
- Finalizar el trabajo de limpieza de lib.syntax (interrumpir dependencias).
- Optimización de Starlark: entorno plano, compilación de bytecode
- Borrar toda la serialización de la fase de análisis, si es posible
- Crear un plan para simplificar o optimizar lib.packages
Comunidad:
- Publicar un glosario con definiciones para todos los términos específicos de Bazel