Ú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 devem ser capazes de acessar implementar as próprias regras e oferecer suporte a novas linguagens e ferramentas. Queremos melhorar a experiência de escrever e manter essas regras.
Nós nos concentramos em duas áreas:
- Torne a linguagem e a API simples, mas eficientes.
- 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. Desencorajar macros sem nome e garantir que o nome seja exclusivo literal de string. Este trabalho tem como foco a base de código do Google, mas pode afetar disponibilizadas ao público.
- P0. Tornar os comandos do Buildozer confiáveis em relação a seleções e variáveis.
- P1. Fazer com que o Buildifier remova cópias em listas que não classificamos devido a comentários.
- P1. Atualização do linter do Buildifier para recomendar expressões triviais em linha.
- P2. Estudar casos de uso de native.existing_rules e propor alternativas.
- P2. Estude casos de uso para o arquivo de prelúdio e proponha alternativas.
Desempenho:
- P1. Otimizar o intérprete Starlark usando ambientes simples e bytecode compilação.
Redução da dívida técnica:
- P0. Foi adicionada a capacidade de fazer a portabilidade de símbolos nativos para o Starlark em @bazel_tools.
- P1. Exclua sinalizações obsoletas (algumas delas ainda são usadas no Google, por isso 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 sinalizações a seguir podem ser ativadas 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 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_python
é ativo e bem mantido pela comunidade. - Suporte contínuo para rules_jvm_external (sem solicitações de envio pendentes, problema) triagem, lançamento de lançamentos).
- Manter a infraestrutura de documentação do Bazel: centralizar e canonizar o CSS estilos no site do bazel, blog do bazel, documentos
- Documentos do Bazel: adição de testes de CI para build do site do documento e2e para evitar regressões.
1º trimestre de 2020
Integridade do build e práticas recomendadas:
- Permitir que os destinos rastreiem a pilha de chamadas macro para exportar via
bazel query
- Implemente o
--incompatible_no_implicit_file_export
. - Remoção das APIs de desativação descontinuadas (#5817, #10313, #9017).
- Adicionar um analisador de vários arquivos no Buildifier, implementar uma verificação de versões descontinuadas .
Desempenho:
- Os testes baseados em Java do Bazel duas vezes mais rápidos.
- Implementar um criador de perfil de CPU do Starlark.
Redução da dívida técnica:
- Remova oito sinalizações incompatíveis (depois de invertê-las).
- Concluir o trabalho de limpeza da lib.syntax (interromper dependências).
- Otimização do Starlark: ambiente simples, compilação de bytecode
- Exclua toda a serialização da fase de análise, se possível
- Criar um plano para simplificar/otimizar o lib.packages
Comunidade:
- Publicar um glossário com definições para todos os termos específicos do Bazel