Starlark 路线图

报告问题 查看源代码

上次验证日期:2020 年 4 月 21 日更新历史记录

联系人劳伦特尔

目标

我们的目标是让 Bazel 更具可扩展性。用户应该能够轻松实现自己的规则,并支持新的语言和工具。我们希望改善编写和维护这些规则的体验。

我们主要关注两个领域:

  • 让语言和 API 简单而强大。
  • 为读取、编写、更新、调试和测试代码提供更好的工具。

2020 年第 2 季度

构建健康和最佳做法:

  • 0. 不建议在没有名称的情况下使用宏,并确保名称是唯一的字符串字面量。这项工作侧重于 Google 代码库,但可能会影响公开提供的工具。
  • 0. 使 Buildozer 命令在选择和变量方面变得可靠。
  • 1. 让构建器移除由于评论而未排序的列表中的重复项。
  • 1. 更新了构建器 linter,以建议内联简单的表达式。
  • P2. 研究 Native.existing_rule 的用例并提出替代方案。
  • P2. 研究前序文件的用例并提出替代方案。

性能:

  • 1. 使用平面环境和字节码编译来优化 Starlark 解释器。

技术债务减少:

  • 0. 添加了将原生符号移植到 @bazel_tools 下的 Starlark 的功能。
  • 1. 删除过时的标志(其中一些仍然在 Google 中使用,因此我们需要先清理代码库):incompatible_always_check_depset_elementsincompatible_disable_deprecated_attr_paramsincompatible_no_support_tools_in_action_inputsincompatible_new_actions_api
  • 1. 确保在 Bazel 4.0 中可以反转以下标志:incompatible_disable_depset_itemsincompatible_no_implicit_file_exportincompatible_run_shell_command_stringincompatible_restrict_string_escapes
  • 1. 完成 lib.syntax 工作(API 清理、与 Bazel 分离)。
  • P2. 将对 Bazel 的 Java 软件包进行细微修改的构建和测试延迟时间缩短 50%。

社区:

  • rules_python活跃,且由社区维护良好。
  • 持续支持 rules_jvm_external(无待处理的拉取请求、问题分类、发布)。
  • 维护 Bazel 文档基础架构:跨 bazel-website、bazel-blog、docs 对 CSS 样式进行集中化和规范化处理
  • Bazel 文档:为 e2e 文档网站构建添加持续集成测试,以防止回归。

2020 年第 1 季度

构建健康和最佳做法:

  • 允许目标跟踪其宏调用堆栈,以便通过 bazel query 导出
  • 实现 --incompatible_no_implicit_file_export
  • 移除了已弃用的 depset API(#5817、#10313、#9017)。
  • 在 Buildifier 中添加跨文件分析器,实现对已弃用的函数的检查。

性能:

  • 使 Bazel 自己的基于 Java 的测试速度提高 2 倍。
  • 实现 Starlark CPU 性能分析器。

技术债务减少:

  • 移除 8 个不兼容的标志(在翻转之后)。
  • 完成 lib.syntax 清理工作(破坏依赖项)。
  • Starlark 优化:平面环境、字节码编译
  • 尽可能从分析阶段删除所有序列化
  • 制定简化/优化 lib.packages 的计划

社区:

  • 发布包含所有 Bazel 专用术语定义的术语表