We ended up setting up a self-hosted GitHub Actions runner, on a hosted Mac M1. Getting the machine itself up and running was easy, thanks to MacStadium's simple, effective UX. But setting up the GHA runner on it was a little trickier, for a couple of reasons...

Rather than forcing global or per-project lockfiles, Pants uses a hybrid approach...This allows a repo to operate with the minimum number of lockfiles required to support their conflicting library versions, without necessarily going to the costly extreme of per-project lockfiles.

Working effectively in a monorepo requires appropriate tooling. While Pants can be a really useful system in repos of all sizes and architectures, it has some features that make it particularly appealing in a monorepo setting…

If you're responsible for your organization's codebase architecture, then at some point you have to make some emphatic choices about how to manage this growth in a scalable way. There are two common architectural alternatives to choose from...

Pants's codegen support solves one of the biggest problems with code generation: how to make sure that local developers, CI, and production are using the same generated code?