I thought about using it at a small scale, but frankly I find more value in a visual representation, and once I have that I don't want to explicitly blacklist imports: those rules can already be derived from the graph (i.e. any import that introduces a cycle is a violation).
Doing it manually allows me the following:
1. I get to define what are the namespaces (domains) that matter, irrespective of the package structure. E.g. import from stripe.api_resources is still a dependency on stripe, not on stripe.api_resources.
2. Work around a bunch of dependency caveats (frameworks like Django do runtime imports and mix high and low level concepts in settings, db foreign keys might inverse your dependencies, etc)
3. Violations are very easy to see: they are cycles in the graph, i.e. arrows pointing upwards. Those are typically design flaws. Though I still allow certain violations because practicality beats purity.
4. Since some violations are allowed, I get to decide how to arrange the graph so that it is more clear what is the flaw and how to address it.
I haven't found a good tool that allows me to get all of these. One day I'll have to build it myself.
Great points. My ideal choice would be having both: visualization & rules as code. :-)
* Visualization gives a better overview.
* Rules as code allows more fine-tuning. E.g. explicitly allowing those few exceptions you mentioned in point 3.
To your points:
1. I absolutely agree. No dependency to Stripe also means no dependency to any of Stripe's subpackages. (The article should probably emphasize this more.)
2. This is a good point. The rules generated for Sourcery only check `import` and `from ... import` statements. Runtime imports are (for now) out of scope.
