I have some more organizational questions for people who have successfully integrated pants for managing their monorepo(s) • do you have roles / people specifically responsible for developing and maintaining the build system? or are most developers expected to learn Pants and be able to integrate their code with it when they need to have artifacts built / deployed? Pants is quite powerful but also seems quite complex, I worry a bit about it being an impediment to developers on my team being able to deploy code. maybe it's not that big of a deal once it gets set up? • do you build additional tooling on top of Pants? I can already see some strong use cases for creating custom targets for deploying artifacts to Databricks and Dagster so they can be used there. are there other kinds of Pants-related tooling you've created or use to help make it easier for developers to get building? • any recommended reading for supporting and structuring monorepos and teams that work with them?

To answer in order • We expect everyone to have a mutual ownership and use the tool correctly. The biggest obstacles have been teaching people to use dependencies correctly when they can't be inferred. We do have a few folks who have become identified as "system experts" that help with the more challenging problems • We build macros and other things to keep folks abstracted from as much as possible. Then just let them pattern match until a new use case comes up. • None for supporting code structure. I did write up a more verbose Astranis case study here.

1. One person (me) has done almost all of "core"/setup/is the expert, but I expect/encourage others to at least crib off the rest of the code to be able to add new artefacts similar to existing ones (i.e. I'm not the only one adding new targets). We're a very small team, though, so having two deep experts (unless one of the others wanted to) isn't appropriate/necessary. 2. Macros, and aliases (e.g.

local = "tailor update-build-files fmt lint check ::"

so that

pants local

does all the simple stuff)

1. We have people with "Build Eng" in their title, but its the people that are looking for new features and new ways to make what we're doing better. Engs are expected to be able to integrate their code into the monorepo on their own (or ask for help). Pants does a great job of making the bar for entry reeeeeally low a. An example is we provide/maintain a macro for building docker images performantly. Engs should be able to cargo-cult enough

BUILD

to leverage the macro 🙂 2. Everything I write that interfaces with Pants I try really hard to upstream. It's how I eventually became a contributor and maintainer of the project. Our "plugin API" is extremely unstable, so it also means that if someone breaks the API they have to fix my plugin because its in the Pants repo 😉 3. I don't think I have an original thought here. The only thing I'll say is you don't have to get it right the first time. Try something and if it doesn't fit, feel free to try something else. Pants is flexible so it shouldn't be getting in your way 😉