That’s great to hear. Is there any page that documents the architecture of pants? I understand build systems of various kinds quite well, but I can’t tease out the design philosophy behind pants, especially how the different target types / plugins end and the “core” begins.

I’m going to dig into that 2.0 link though!

There isn't, but that's a good idea. At a very high level, the v2 engine is "Skyframe but using async Rust". All filesystem access, snapshotting, UI, and networking is in Rust, and we use the Bazel remote execution API to allow for remote execution. The v2 plugin API is side-effect free Python 3 async functions (called `@rules`) with a statically checked, monomorphized, dependency-injected graph connecting plugins (ie, we know before executing whether the combination of plugins forms a valid graph). Unlike plugins in Bazel, `@rules` are monadic, so they can inspect the outputs of other `@rules` in order to decide what to do.

This file contains a few good examples of `@rule`s that collectively partition python targets to generate `setup.py` files for them automatically: https://github.com/pantsbuild/pants/blob/5e4f123a1dbc47313fe...