lemon-computer-3698103/22/2021, 10:52 AM
I found a couple example repos, e.g.
But I have a couple other questions, that I'll ask here. If someone can advise that'd be awesome 🙂
Is it ok to have inter-project source code dependencies, or is it better to extract all shared source code to some
Is it better to keep projects in
or just lay them all out in
How well does PyCharm work with a monorepo project structure? Is it simple enough to resolve import paths, virtualenvs per project etc.
flat-zoo-3195203/22/2021, 2:19 PM
Is it ok to have inter-project source code dependencies, or is it better to extract all shared source code to someIt's gonna be up to you and your team(s) to decide what works best. If you're primarily building mostly unrelated applications, then putting shared code inprojects?
could make sense, but if you could also choose other ways to go about it depending on the character of the code you want to manage here, and how you want your concept of code-ownership or stewardship to work.
I used a tree like:
/$company/algorithms/... # Classic CV algorithms and wrappers
/$company/applications/... # CLI applications
/$company/backends/... # Backends for externally provided features
/$company/blueprints/... # Microservice blueprints for shared routes
/$company/launchers/... # Code to help applications launch in containers and dev environments
/$company/models/... # CV models and associated code
/$company/services/... # Named microservices
/$company/tools/... # tools used to work with code
/$company/types/... # Shared type names for communicating across layers
only depended on the other parts, which were mostly independent-ish library elements, and
was at the bottom, providing some common vocabulary and functions to encourage a more uniform way of communicating data between components. This was set up this way to encourage greater code re-use. So i guess rather than marking shared code as
, we assumed library code, and then made app/service code explicitly marked.
Another way to do divide a monorepo is project-first, which just puts each project in its own directory. It's also a valid choice. All this is going to come down to what you think will work best for your team and environment, and what kinds of behaviors you want to encourage.
happy-kitchen-8948203/22/2021, 3:11 PM
directory or something similar.
flat-zoo-3195203/22/2021, 3:18 PM
lemon-computer-3698103/22/2021, 3:54 PM
flat-zoo-3195203/22/2021, 4:43 PM
The team are concerned about versioning e.g. if a project needs some urgent update which ends up breaking some other project in the process. At the moment we can version stuff and deploy to pypi. It's another element where I don't understand best practice (keep it on a separate branch? In some `v1`/`v2` subdirectory?)The short answer is to avoid this situation as best you can. Monorepos are really at their best when they work in service of maintaining a single source of truth in a single place. If you start long-term maintenance of branches, then you're just moving multirepo problems into a single place. Consider gating features with flags rather than branch-based solutions. Namespace solutions like v1/v2 are best used for when you need to rewrite a whole feature or library that violates fundamental assumptions built-in to the previous version. I'd say you can use branching for ephemeral hotfix-kinda stuff or as part of a release cycle plan (as pants itself does), but you don't want to get into a situation where you're maintaining some forked version of your code long-term, as this will come around to bite you