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.
* 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.