Soliciting opinions on an idea for improved onboarding/developer experience/make-my-life-marginally-easier (which I'm going to build regardless, but just opinions on what we need): We currently have isolated example repos for several backends, but I was thinking of some sort of "kitchen sink" approach, which would be a single monorepo (or a single repo, with submodules 🤷). Not proposing that each backend talks to each other, being completely isolated is just fine - but the idea is showing how a monorepo could be setup. Some benefits: • Non-trivial Pants repo setups can benefit new users (or existing people like me, who forget how config should look sometimes) • For a sophisticated enough repo, plugin development test runs cover a wider array of code (issue for me right now with

pyright

working sometimes, but not other situations) • [Another thing I forgot] Questions: What should the scope of each of these backend examples be (reasonable middleground). • 1st party code • 1st party lib/dep (in another folder/repo) • 3rd party deps • Codegen • ???

the most useful scope will be a realistic scope, rather than necessarily defining it as “kitchen sink”

the most useful scope will be a realistic scope

Kinda disagree here, as there are so many possible permutations - and people can write microservices in whatever language(s) they want (for example). I use, in 1 repo: Shell, C, C++, Swift, Python - so that's realistic for me, but is it for others? 🤷 One of the best examples of this kitchen sink I can think of is react-table, which has an example with almost every feature that it's capable of, even though no realistic use cases uses them, but devs can cherry pick what they need. It's also quite a showcase to say

./pants fmt lint check package ::

and then have everything "just work". So, lets potential users know that, regardless of their plan going forward - they're covered. Having a repo like this, I think also introduces some uniformity to the example base

One of the best examples of this kitchen sink I can think of is react-table, which has an example with almost every feature that it’s capable of, even though no realistic use cases uses them, but devs can cherry pick what they need.

this works when the features don’t need to interact with one another… with

pants

, you’re necessarily going to end up with a bunch of stuff in

pants.toml

, and each individual example gets less clear the more you add.

Right, what I mean is there is no "realistic scope" for an example repo, it's more like what happens today with a bunch of individual backends, or an all-in-one. The some-in-one approach I feel has the least use. I agree with possibly cluttering up the

pants.toml

though, if there are a lot of custom settings.

there is no single realistic scope, but there are multiple realistic scopes