Simplify and Standardize Starlark APIs

[sluongng]

Over the recent years, there have been multiple attempts at trying to build a replacement for Bazel from scratch. I personally know of 3 different attempts at different scales and tradeoffs, with https://github.com/buildbarn/bonanza/ being the prime example in the OSS ecosystem.

The rebuild attempts have one thing in common: while they are making newer design decisions with different tradeoffs to enable newer use cases, they all tried to adhere to the same set of Starlark APIs, which Bazel implemented for the repository rules (and Bzlmod as an extension) and the build rules. This way, they benefit from the established Bazel ecosystem and community.

Personally, I view these attempts as a healthy thing to have in the build tool ecosystem. They bring newer ideas and challenge the status quo. I think we should embrace these efforts as much as possible by supporting them and learning from them to improve the core system as a whole. For example, I know that @EdSchouten has made many bug fixes and improvements to the rules ecosystem as part of implementing Bonanza, specifically in rules_cc and rules_go as well as in some parts of Bazel.

---

With that said, I think there are 2 proposals that should be put forward for consideration.

Simplify the native Starlark API

Over the years, more and more features have been added to repository_ctx and buildaction_ctx. Some of them made sense at the time, but many of them have become bloat overtime and make it harder / taxing for a build tool to implement and adopt.

A simple example would be ctx.actions.run_shell can be reimplemented as Starlark using ctx.actions.run. There is no good reason why we should still need a specific run_shell function in the ctx.actions api.

We should tighten these api over the next 2-3 releases of Bazel and replace them with Starlark implementations wherever applicable. A smaller native starlark api surface should decrease the maintenance burden and make it easier to swap out the actual build tool implementation underneath.

This feels like the right next step now that rules_cc and rules_java have been migrated to Starlark.

Standardize Bazel Starlark APIs

I think folks who are trying to implement a Bazel replacement have found various successes when reusing the work from Bonanza at https://github.com/buildbarn/bonanza/tree/main/starlark.

However, this curation from Bonanza is very subjective. Actual API needs to couple together different core rule sets (cc, java, shell) releases to ensure compatibility, as well as Bazel releases. Such an effort is not feasible without the backing of the Bazel team and the community as a whole.

[EdSchouten]

A simple example would be ctx.actions.run_shell can be reimplemented as Starlark using ctx.actions.run. There is no good reason why we should still need a specific run_shell function in the ctx.actions api.

I fully agree. That could just be some utility function in rules_shell at this point.