Ú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 ser capazes de implementar facilmente as próprias regras e oferecer suporte a novas linguagens e ferramentas. Queremos melhorar a experiência de criação e manutenção dessas regras.
Nós nos concentramos em duas áreas:
- Torne a linguagem e a API simples, mas poderosa.
- Fornecer ferramentas melhores para ler, escrever, atualizar, depurar e testar o código.
2º trimestre de 2020
Integridade do build e práticas recomendadas:
- P0: Desencoraje macros sem ter um nome e garanta que o nome seja um literal de string exclusivo. Este trabalho tem como foco a base de código do Google, mas pode afetar as ferramentas disponíveis publicamente.
- P0: Torne os comandos do Buildozer confiáveis em relação a seleções e variáveis.
- P1. O Buildifier agora remove as cópias em listas que não classificamos por causa de comentários.
- P1. O linter do Buildifier foi atualizado para recomendar expressões triviais inline.
- P2. Estude os casos de uso de native.existing_rules e proponha alternativas.
- P2. Estude casos de uso para o arquivo de prelúdio e proponha alternativas.
Performance:
- P1. Otimizar o intérprete de Starlark usando ambientes simples e compilação de bytecode.
Redução da dívida técnica:
- P0: Foi adicionada a capacidade de transferir símbolos nativos para o Starlark abaixo de @bazel_tools
- P1. Exclua as flags obsoletas. Algumas delas ainda são usadas no Google, então precisamos
limpar a base do 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 sinalizações a seguir 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. Conclua o trabalho de lib.Syntax (limpeza de API, separação do Bazel).
- P2. Reduza em 50% a latência de build + teste de uma edição trivial nos pacotes Java do Bazel.
Comunidade:
- O
rules_pythoné ativo e bem cuidado pela comunidade. - Suporte contínuo a rules_jvm_external, sem solicitações de envio pendentes, triagem de problemas e criação de versões.
- Manter a infraestrutura de documentação do Bazel: centralize e canonize estilos CSS em bazel-website, bazel-blog, docs.
- Documentos do Bazel: adicione testes de CI para a compilação do site do documento e2e para evitar regressões.
1º trimestre de 2020
Integridade do build e práticas recomendadas:
- Permitir que os destinos acompanhem a pilha de chamadas de macro para exportar usando
bazel query - Implemente o
--incompatible_no_implicit_file_export. - As APIs descontinuadas foram removidas (5817, 10313 e 9017).
- Adicione um analisador de vários arquivos no Buildifier e implemente uma verificação de funções descontinuadas.
Performance:
- Torne os testes baseados em Java do próprio Bazel duas vezes mais rápidos.
- Implementar um criador de perfil de CPU Starlark.
Redução da dívida técnica:
- Remova oito sinalizações incompatíveis (depois de invertê-las).
- Conclua o trabalho de limpeza de lib.Syntax (quebra dependências).
- Otimização do Starlark: ambiente plano, compilação de bytecode
- Se possível, exclua toda a serialização da fase de análise
- Criar um plano para simplificar/otimizar as lib.packages
Comunidade:
- Publicar um glossário com definições para todos os termos específicos do Bazel