Gotcha, understood. Mirroring @Denzel's edit, I think that rationale makes sense for configuring some of the intermediate glue which is project-specific. For in

Gotcha, understood. Mirroring @Denzel's edit, I think that rationale makes sense for configuring some of the intermediate glue which is project-specific. For instance, running test suites, orchestrating deployment, and other more custom actions which aren't terribly reusable across projects (think Bazel's 'genrule'). Caching test results in a distributed way is a great use case, and environment isolation (i.e. without forcing the user to define a Dockerfile or similar, and leaving environment configuration to the build system) seem like great use cases. However, I think for describing actual build toolchains this way of implementing things might end up being significantly more complicated (and require even more arcane end-user cognitive load) than the Starlark/Python-based build rule / toolchain / constraint approach for actually assembling libraries, binaries, and other compiled artifacts. There are a combinatorial number of backends, conditional options settings, etc. which will be hard to capture with a purely declarative system. For instance, a C++ binary might needs platform-specific compiler flags, or some #ifdef nonsense. YAML doesn't have a clean way of implementing conditionals based on some constraint. So for heterogenous ecosystems (C/C++, Python, container assembly, GPU development, microcontrollers, etc.) this pushes a ton of complexity into the build rules themselves which may be opaque to end users (and thus introduce a ton of cognitive load, steep learning curves, hard-to-debug errors, etc.).