Thanks! You can think of Grimp as a lower-level tool for interacting with the import graph in Python, while Tach is a high-level tool responsible for 'modularity' as a whole (e.g. modules, interfaces, layers, deprecations etc.)
Tach is also more opinionated - so it doesn't require you to write any custom code, and uses declarative config to enforce your desired architecture.
borplk hit this right on the head - the public/private distinction not sufficiently nuanced enough to handle the requirements of more complex codebases.
To put your example in other words, I simply want baz scoped to foo. baz may be public for all members and sub-modules of foo, but external uses of baz outside of foo would create brittle and unwanted dependencies across my codebase.
My experience primarily comes from scale-ups, where the companies grew fast and hired fast.
Without putting specific companies on blast, I hear about this problem consistently from growth stage startups that scaled on Python. It's a common reason people reach for microservices - trying to use network boundaries to cover for the lack of module boundaries.
Ideally you can trust coworkers; unfortunately that's not always the case. Here's a quote from a developer in response to the article in another forum:
"""
It can even be very useful sometimes to be able to import private stuff. In a large ecosystem where you use many modules from other teams, you might need to use some private functionality.
"""
If something is available for an individual developer that solves their problem, often they're not thinking about the fact that it's private or creates a brittle dependency with no contract.
There's a decent (if fairly biased) comparison on monorepo tooling here: https://monorepo.tools/
Note that it's written by nx.dev (TS monorepo tool), so well worth taking the specific comparisons with a large grain of salt. Useful to understand what is out there though!
Bazel (originating from Blaze inside Google) is great but very heavy/takes a lot of work to adopt. It's likely the gold standard if you're working with a large polyglot repo.
As a python dev, I've been frustrated with existing solutions, which is why we built Tach to solve some of the problems we've faced, particularly around organization and isolation - https://github.com/gauge-sh/tach
Pants is another great build system out of Twitter that has seen widespread adoption - https://www.pantsbuild.org/
Typically teams won't have access to the code that's being deployed on the other side of the network boundary. This physical separation is overkill though; something like CODEOWNERs and https://github.com/gauge-sh/tach can do this without incurring remotely the same overhead.
Google famously still primarily maintains a monorepo, but they absolutely don't deploy a monolith. They published a paper last year that describes an approach that is quite close to what they have internally - https://dl.acm.org/doi/pdf/10.1145/3593856.3595909
Effectively, by setting strong boundaries between modules, they can develop on their application as if it was a monolith, but at runtime, separate those modules physically deploy them as micro-services. This solves a lot of the versioning issues (since the app is rolled out atomically) and correctness issues (easier to reason through a monorepo).
reply