Does anybody here have any sample directory layouts for a multiproject multilanguage monorepo? Specifically I'm looking to see how people deal with source root when they have many top level projects that may have multiple languages nested within them. Something like. Any opinions or input at all is appreciated, thanks!

SharedLibs
  LibraryType1/
    src/
      python/
      go/
      js/
Project1/
  ops/
  src/
    python/
    go/
    js/
  docs/
Project2/
  ops/
  src/
    python/
    go/
    js/

The way I tend to line up mine are top-level projects, or if there are many, then there might be some added namespacing (e.g. backend/frontend - just to limit the number of dirs), and then the project (however the language/framework wants to set it up). I don't think I've ever used the language as a namespace, because that's generally an implementation detail that doesn't particularly matter. This is a contrived example. Each of these projects has a single BUILD - so my projects generally have 1 BUILD file per "project" or per "repo" or whatever you'd call that, then then 1 top-level BUILD and 1 top-level pants.toml

backend/api <-- Python FastAPI
backend/gateway <-- nginx
backend/foo <-- Rust
libs/lib1
libs/lib2
frontend/cli <-- Rust
frontend/web <--Sveltekit
frontend/admin <-- Sveltkit

Ok thanks this is helpful. Although i think for us we have many different systems so backend/frontend split wouldn't make sense. I'm thinking of breaking up the directories by logical domain (boundec context in DDD terms). This way you may have a bounded context, and WITHIN that there may be different services or projects. Any given project could have multiple different language applications within it. I think youre right though, I may be able to omit language as a directory name. I'm coming from the world of please where there is NOT any automatic inference so i thought maybe this would be needed for ease of use with some inference stuff, or for libraries that provide different languages (you know like a SDK that is available in multiple languages)

Yeah, however the splits make sense - in a lot of cases, I just have top-level projects and that's enough. The only instance where I do use languages, is pants-related stuff (e.g. examples of pants stuff by backend, which is basically language at some level: https://github.com/sureshjoshi/pants-plugins/tree/main/examples) The cool thing is that you can mostly split up things how you please. I would treat automatic inference with some caution though - as while it CAN do a lot of stuff - for technical debt/maintainability purposes, its sometimes nice to be a bit more explicit (or even maybe use visibility rules). It can become really easy to just pull file x from project y otherwise

Yeah, automatic inference makes me nervous if im honest. I think im much more comfortable explicitly defining sources. I just didn't know if i was being a rigid old man or not haha

Well, I guess, it's a combination of things. As an example, I'm a recursive glob kinda person with BUILD files. not everyone else is 🤷 I want to have my project known about, with minimum build files - but make sure everything knows about each other in the right ways. I view it as just managing dependencies. Within a single lib/sub-app I'm a bit more liberal in allowing stuff to see each other, but when it comes to apps and libs talking to each other, that's always explicit - in the same way I would treat a 3rd party dep

Yeah. I’m more just trying to make sure I understand what’s idiomatic for pants. I’m used to how to organize my build files with Bazel and please. I think it’s probably just a matter of me becoming more comfortable with pants so I can act with confidence