I'm mainly team monorepo because working with git submodules is such an needlessly miserable experience.
At work we have a pretty large project with many teams having moved to using nested git submodules for their stuff.
Whenever you checkout a commit you basically have do a `git submodule --init --recursive` and pray there's no random files left over because some submodule has moved and git-submodule thinks it's your job to clean up its mess. This becomes really annoying when you want to bisect something.
Surely there must be a saner way to deal with trees of git repos. I guess AOSP uses its own `repo` tool to do multirepo stuff which might be better. But honestly this _should_ be fixable in git-submodule itself if they just make it behave sanely.
By the time you have so much code that you benefit from a monorepo, you probably have so much code that you benefit from working in a statically typed language, and addressing that first will probably give you concrete benefits faster.
Most of the time, the CI resources in a python monorepo is not spent on packaging. It’s spent on running the tests.
I would love to read more about how the author is tackling the testing problem in their setup.
I'm mainly team monorepo because working with git submodules is such an needlessly miserable experience.
At work we have a pretty large project with many teams having moved to using nested git submodules for their stuff.
Whenever you checkout a commit you basically have do a `git submodule --init --recursive` and pray there's no random files left over because some submodule has moved and git-submodule thinks it's your job to clean up its mess. This becomes really annoying when you want to bisect something.
Surely there must be a saner way to deal with trees of git repos. I guess AOSP uses its own `repo` tool to do multirepo stuff which might be better. But honestly this _should_ be fixable in git-submodule itself if they just make it behave sanely.
Reads more like an advertisement for dagger than anything else, unfortunately.
By the time you have so much code that you benefit from a monorepo, you probably have so much code that you benefit from working in a statically typed language, and addressing that first will probably give you concrete benefits faster.
How is any of this relevant to the article?