Tach is a pip package that lets you define module boundaries, automatically detect all cross-module dependencies, and then validate and enforce those dependencies. It also supports strict interfaces for modules by overloading `__all__`. The core static analysis is done in Rust, so all Tach commands run quickly. The goal of Tach is to help eng teams maintain velocity while scaling quickly, something we've seen break down a number of times. Give it a try! |
It seems you can define an extra level of who's allowed to import what...but why would I want to add that on top rather than using standard conventions? Why would I want to let foo import baz, but not let bar import baz?
In large codebases you can have a problem where people randomly import things from different locations leading to a host of issues including circular import issues.
For example someone finds a convenient helper function in "my_thing.foo.bar.helpers" and imports it but you don't want that dependency between those modules and the helper function was not intended to be used outside of that module.
In Python this problem is especially severe because there is no native module encapsulation mechanism other than a weak conventio of using the underscore prefix.
A tool like this helps you enforce "intentional" module boundaries so modules can't randomly reach into each other to import things. You will be forced to consider an intentional modular design where the helpers that are needed by many things are separated out and other things are allowed to import from it.
IMO it's unfortunate, especially because of that behaviour, that they're importable (explicitly) at all.
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.
[0] https://www.gauge.sh/blog/python-extensions-should-be-lazy
Especially in a large codebase where lots of different modules are technically in the same package as each other.
It's easier when a library author is publishing a small package for external consumption by other parties.
Another issue is that in Python any name in a module is implicitly available to be imported from other places.
For example let's say you have "A.py" inside of "A.py" you have "from something import foo". Now "B.py" can do something like "from A import foo".
So now "B" has a dependency that nobody really wanted to create.
Later "foo" may not be needed in "A.py" anymore and it will look like a totally unused import to anyone. Except it is being used by "B.py" too behind your back.
Someone deletes the "unused import" and something else somewhere else breaks because it can no longer import "foo" from "A".
(I have seen variations of this issue happen many many times so don't think I'm making some theoretical scenario.)
I'm not sure what use-case this serves, as all my library "don't be naughty" needs are handled by my IDE.