So, yes, I got to the same conclusion. Basically, solve every part of the problem:
- in isolation/as focused as possible
- as a library
- with the easiest to use and most composable API you can come up with
After that, if you have to, you can still glue them together into a framework-like thing. But at least, anyone can pick any feature out of it without succumbing to madness. Also, this is a great way to avoid the whole "Big Ball of Mud" problem that forces you to pull a whole ecosystem into your project although all you wanted to do was log something.
I use Ansible quite a bit. When I first started, based on some examples I found, my play books were pretty complicated, with a lot of conditional steps, doing things (or not) based on results of previous steps, etc.
What I found is that it's a lot easier to have a lot of roles that each do one little thing, and then use them in a play book as needed.
A role might be as simple as installing a package, templating a configuration file, or maybe even just changing just one line in a config file.
When roles are small and do just one thing, they are easy to combine in many different ways, and it's more obvious what's going on.
If you go with largish modules you need to be smart when you build it, if you build smaller modules you don't have to be that smart. Dumb is good, dumb is easier to explain and read for others (including yourself in 3 years).
So, be dumb keep it simple, whatever that is in your case. If the code is easy maybe a giant repo is good, if the team is small. If the team is big maybe you have other means of validating access to your repo, but if not you need to split it up. But then commits need to be synced when pushed over several repos..
Edit: make sure it's possible to make clean commits and rewrite the whole code in small steps. Things Will Change(tm)