Hey! I work at a payment processor. I'm taking a quick look into build tools that hopefully 1. support a variety of languages (ideally java/rust/python/c++/js) 2. are easy to learn/use and extend (though hopefully we don't need to do much extension) 3. integrate with package managers for 3rd party packages 4. do a decent job of caching so we don't need to "build the universe" any time something changes

Hi Liam, welcome! For C++, @wide-midnight-78598 has been doing some exploratory work and landed some commits in pantsbuild/pants. For Rust, @fast-nail-55400 has been thinking through what it might look like. We're definitely eager to better support JS, Rust, and C++, and would be happy to partner with someone looking to add any of those, such as pair programming Pants is intentionally designed to be extensible, and we now have 6 languages (Go, Python, Java, Scala, Kotlin, Shell) so experience w/ differnet paradigms

Still early days but I'm definitely excited about pants (mostly due to my perception that it'll have a quicker on-ramp than other similar build tools and that extension will be simpler). Does any documentation exist on suggested patterns for moving from a code base consisting of many different repos, languages, and build tools to a monorepo + pants? Something I've briefly considered is a monorepo root that includes our existing repos as git submodules. I assume this wouldn't play nicely with pants' git integration?

I’ll just add that Pants does a great job at caching work too so you don’t have to re run things that aren’t affected of a particular change.

Does any documentation exist on suggested patterns for moving from a code base consisting of many different repos, languages, and build tools to a monorepo + pants?

https://www.pantsbuild.org/docs/existing-repositories is our current guide on adopting in repos. Although we certainly want to expand that. The recent Astransis case study takes a similar approach https://blog.pantsbuild.org/astranis-case-study-wrangling-python-in-a-monorepo/

Something I've briefly considered is a monorepo root that includes our existing repos as git submodules. I assume this wouldn't play nicely with pants' git integration?

Yeah I think it would work less well. I haven't used submodules closely, but my understanding is it goes against the monorepo appraoch of everything being at HEAD: https://blog.pantsbuild.org/the-monorepo-approach-to-code-management/ I believe you could do an incremental thing where you set up Pants for each distinct submodule. It would make sharing across the projects harder, but could be an incremental step What's your motivation with submodules?

What's your motivation with submodules?

We use a lot of tooling tied to a multi-repo approach (kicking off CI, managing PR approvals, etc.) that we'd need to move away from. I was hoping we'd be able to set up a monorepo that initially contains submodules that then, over time, become part of the monorepo proper. It sounds like the more standard approach would be to convert each repo to use pants for builds and only then attempt consolidation into a monorepo?

It might be worth posting in #general for advice on that, if others have experience here. You're not alone with going from multirepo to monorepo. But yeah, I know many folks do take the approach of keeping the repos separate to begin with. Pants is designed to work well still in multirepos Generally, we're big fans of incremental migrations to reduce risk