Ú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 conseguir implementar as próprias regras com facilidade e oferecer suporte a novos idiomas e ferramentas. Queremos melhorar a experiência de escrever e manter essas regras.
Nosso foco é em duas áreas:
- Crie uma linguagem e uma API simples, mas eficientes.
- Oferecer ferramentas melhores para ler, gravar, atualizar, depurar e testar o código.
2º trimestre de 2020
Integridade da build e práticas recomendadas:
- P0. Desencoraje macros sem nome e garanta que o nome seja um literal de string exclusivo. Este trabalho se concentra na base de código do Google, mas pode afetar ferramentas disponíveis publicamente.
- P0. Tornar os comandos do Buildozer confiáveis em relação a seleções e variáveis.
- P1. Faça o Buildifier remover duplicatas em listas que não são classificadas devido a comentários.
- P1. Atualize o linter do Buildifier para recomendar a inclusão de expressões triviais.
- P2. Estude casos de uso para native.existing_rules e proponha alternativas.
- P2. Estude casos de uso para o arquivo de prelúdio e proponha alternativas.
Desempenho:
- P1. Otimize o interpretador Starlark usando ambientes simples e compilação de bytecode.
Redução da dívida técnica:
- P0. Adiciona a capacidade de portar símbolos nativos para Starlark em @bazel_tools.
- P1. Exclua flags obsoletas (algumas 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 seguintes flags 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. Concluir o trabalho de 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:
rules_pythoné ativa e bem mantida pela comunidade.- Suporte contínuo para rules_jvm_external (sem solicitações de pull pendentes, triagem de problemas, criação de versões).
- Manter a infraestrutura de documentação do Bazel: centralizar e canonicalizar estilos CSS em bazel-website, bazel-blog e docs
- Documentos do Bazel: adicione testes de CI para build do site de documentação e2e para evitar regressões.
1º trimestre de 2020
Integridade da build e práticas recomendadas:
- Permite que os destinos rastreiem a pilha de chamadas de macro para exportação via
bazel query. - Implemente o
--incompatible_no_implicit_file_export. - Remoção das APIs de conjunto de dependências descontinuadas (#5817, #10313, #9017).
- Adicione um analisador de arquivos cruzados no Buildifier e implemente uma verificação de funções descontinuadas.
Desempenho:
- Deixar os próprios testes baseados em Java do Bazel duas vezes mais rápidos.
- Implemente um criador de perfil de CPU do Starlark.
Redução da dívida técnica:
- Remoção de oito flags incompatíveis (depois de invertê-las).
- Concluir o trabalho de limpeza de lib.syntax (quebrar dependências).
- Otimização do Starlark: ambiente simples, compilação de bytecode
- Excluir toda a serialização da fase de análise, se possível
- Faça um plano para simplificar/otimizar lib.packages
Comunidade:
- Publicar um glossário com definições de todos os termos específicos do Bazel