Última verificação: 21/04/2020 (histórico de atualizações)
Ponto de contato: laurentlb
Meta
Nosso objetivo é tornar o Bazel mais extensível. Os usuários precisam poder implementar facilmente as próprias regras e oferecer suporte a novas linguagens e ferramentas. Queremos melhorar a experiência de escrever e manter essas regras.
Focamos em duas áreas:
- Tornar a linguagem e a API simples, mas eficientes.
- Ofereça ferramentas melhores para ler, gravar, atualizar, depurar e testar o código.
2º trimestre de 2020
Práticas recomendadas e de integridade:
- P0. Não use macros sem nome e verifique se o nome é um literal de string exclusivo. Este trabalho está focado no código-base do Google, mas pode afetar as ferramentas disponíveis publicamente.
- P0. Os comandos do Buildozer são confiáveis em relação a seleções e variáveis.
- P1. O Buildifier remove duplicatas em listas que não são classificadas devido a comentários.
- P1. Atualização do lint do Buildifier para recomendar a inserção de expressões triviais.
- P2. Estude casos de uso para native.existing_rules e proponha alternativas.
- P2. Estude casos de uso do arquivo de prelúdio e proponha alternativas.
Desempenho:
- P1. Otimizar o interpretador do Starlark usando ambientes simples e a compilação de bytecode.
Redução da dívida técnica:
- P0. Adicionamos a capacidade de portar símbolos nativos para Starlark abaixo de @bazel_tools.
- P1. Exclusão de flags obsoletas (algumas delas ainda são usadas no Google, então precisamos
limpar a base de código primeiro):
incompatible_always_check_depset_elements,incompatible_disable_deprecated_attr_params,incompatible_no_support_tools_in_action_inputs,incompatible_new_actions_api. - P1. Verifique se as flags de acompanhamento podem ser invertidas no Bazel 4.0:
incompatible_disable_depset_items,incompatible_no_implicit_file_export,incompatible_run_shell_command_string,incompatible_restrict_string_escapes. - P1. Finalização do trabalho da lib.syntax (limpeza da API, separação do Bazel).
- P2. Reduza em 50% a latência de build e teste de uma edição trivial nos pacotes Java do Bazel.
Comunidade:
- O
rules_pythonestá ativo e bem mantido pela comunidade. - Suporte contínuo para rules_jvm_external (sem solicitações de pull pendentes, triagem de problemas, lançamentos).
- Manter a infraestrutura de documentação do Bazel: centralizar e canonizar estilos CSS no site, no blog e na documentação do Bazel.
- Documentos do Bazel: adição de testes de CI para a build do site de documentos e2e para evitar regressões.
1º trimestre de 2020
Práticas recomendadas e de integridade:
- Permitir que os destinos rastreiem a pilha de chamadas de macros para exportação por
bazel query - Implemente o
--incompatible_no_implicit_file_export. - As APIs depset descontinuadas foram removidas (#5817, #10313, #9017).
- Foi adicionado um analisador de arquivos cruzados no Buildifier e implementada uma verificação de funções descontinuadas.
Desempenho:
- Torne os testes baseados em Java do Bazel duas vezes mais rápidos.
- Implemente um profiler de CPU do Starlark.
Redução da dívida técnica:
- Remover oito flags incompatíveis (depois de invertê-las).
- Finalizar o trabalho de limpeza de lib.syntax (interromper dependências).
- Otimização do Starlark: ambiente plano, compilação de bytecode
- Excluir toda a serialização da fase de análise, se possível
- Criar um plano para simplificar/otimizar lib.packages
Comunidade:
- Publicar um glossário com definições de todos os termos específicos do Bazel