Moving all our Python code to a monorepo: pytendi
Organizing code across a company is not an easy task. Even as a relatively young startup with only five developers, we quickly found ourselves tangled in a web of Python repositories. The increasing number of code repositories made it more difficult to discover and reuse existing code, and streamline our development process.
To tackle these issues, we decided to migrate most of our Python code into a single monolithic repository—a monorepo. In this article, we dive deeper into the reasoning behind this decision, the tradeoffs we considered, how we structured our codebase using the Polylith architecture, what benefits and problems we’ve observed so far, and plans for the future.
TL;DR: We migrated our Python codebase to a monorepo, improving discoverability, reusability, and developer experience. The migration wasn’t without challenges, but the benefits in code organization, development speed, and overall productivity have made it worthwhile for our growing team.
As a provider of speech recognition APIs for healthcare, our work involves a significant amount of Python code, particularly for data science and machine learning tasks. Initially, individual repositories seemed manageable, but as our projects and team grew, we encountered several issues:
