If not, I’m specially looking for examples of Python monorepos that are using Pants.

Hi, you can inspect the Pants repo itself.

Thanks. I believe monorepos are not very common in the Python world (at least in public projects), and while I have tried to hack a useful structure (for our use cases) using Make and Poetry, I’m still looking for examples that could lead to better ideas. I will first look (again, actually) at the Pants repo.

The more important question for a monorepo is not, how to build it. It's how to organize code around it. Is it hermetic (3rd party libraries need to be imported into the monorepo), or more hybrid (useage of package manager features)

Indeed, we’re still using external packages (via Poetry), but we want also to manage a set of packages that are developed in-house with some dependencies.

/(repository root)
├── .gitignore
├── pants
├── pants.toml
├── pants\_from\_sources
├── src/
│   ├── docs/[projects]
│   ├── go/[projects]
│   └── python/[projects]
├── test/
│   └── go/[projects]
│   ├── python/[projects]
└── out\_of\_tree/
    └── pants/

This is how i personally like to structure my projects

OK thanks.

i've got a gitignored out of tree directory that takes independent projects with their own git repo

@witty-house-77262 you are right there aren't many public monorepos for Python. I suspect it's a tooling chicken-and-egg problem, they don't exist because the tools don't support them, but why/how would you develop a tool for a use case not seen widely? Luckily Pants has the tooling side covered, so I'd expect as it gains traction and popularity you'll see a few python monorepos pop up

It's more than just tooling. Things like reverse resolution of dependencies for example is so good.

I could easily see Django and it's friends becoming a monorepo. Or sqlalchemy. There are people among this community talking with project maintainers to introduce them to Pants. (Also worth saying you don't need a monorepo to leverage the power of Pants 😉)

I’ve been using Make for the last 30 years, Tox for the last 10, and Poetry for the last 5. Only a change of paradigm can make me adopt a new tool 🙂

The chicken-and-egg thing revolves around the usage of monorepos, imo. It's a cluster of topics with build systems being just one of them.

FWIW going from tox to poetry is already a large paradigm shift. Pants will be an equally powerful shift for you, I think.

I'm working on adding pants to the StackStorm monorepo. https://github.com/st2sandbox/st2/tree/pants Feedback / help welcome!

Thanks @proud-dentist-22844!

I work for Toolchain, the lead sponsor of Pants. We provide a remote caching SaaS for Pants and enterprise support/consulting services for Pants. Because of the business model, we hear from a lot of companies that have a private monorepo or are looking to migrate their polyrepo architecture over to a monorepo. So I can confidently say there is definitely a portion of the Python community that is enthusiastically committed to monorepo arch. But that doesn't deal with the public examples question, unfortunately. I think an important thing from our perspective is that Pants shouldn't coerce you into a particular structure. It doesn't even require a monorepo per se; it's just at maximum useful when applied to that context. May I suggest starting with organizing the structure in a way that makes most sense for your needs, then circle back here if/when Pants gets in the way? Because we sincerely like to hear whenever we can make Pants more flexible and adaptive to a wide range of real-world needs.

It starts with the mental model of monorepos being twisted by tool manufacturers to a degree where the concept is becoming a marketing term (turbo monorepo -> 'turborepo'). 😡I am so enraged by this. I can actually feel hatred building up. And it ends with people being confused to no end. They then look for answers and need to unwind this from the wrong end. And I now feel the need of setting things straight. HAAAA so much anger, I really don't know why this gets under my skin, but there's a lot of frustration.

It doesn't even require a monorepo per se;

Yeah, this is a good point. Pants is meant to work in a polyrepo still. That's a major reason we invested a lot into reducing the boilerplate needed to use Pants, like dependency inference With other build tools like Pants v1 and Bazel, often the value becomes worth it when the repo is large enough to justify the complexity of the tool. We tried to lower that complexity with Pants v2

the beauty behind Pants v2 is flexibility compared to Bazel/Buck/... Pants V2 does not lock you down into a rigid structure, being less opinionated on how to do things. Pants integrates well with existing workflows, existing repositories, existing tools. You don't adapt tools to work with Pants, you adapt Pants to work with tools. There's a big difference to how it fundamentally feels.

It's true that this is very intentional. We set out every day with the vision and mission of making Pants the tool that serves any team's needs in the way they deem best for them, rather than pinned to one company's very specific constraints. Bazel or Buck or Pants 1 are great if you are operating from a set of conditions just like Google's or Facebook's or Twitter's. But if you're not, you end up butting heads with the tool and contorting team practices awkwardly. We don't believe pushing that would be consistent with the project's underlying purposes of code quality and developer joy.

it goes further than that, as far as I am concerned. Usually, the tools you use require a certain workflow as well. It's not just organizational structures that do. Pants lets me decouple tools and processes, it let's me find a workflow that fits my way of thought, my way of working and lets me approach my issues in my way, regardless of the tools I use and the environment I use them in.