Thanks for your response @solnic.
Well, what I actually had in mind was using dry-configurable with dry-auto_inject in the following way (now that dry-configurable can be accessed through a Hash interface it is possible):
# My Gem code
setting :primitive, 'I am a string'
Import = Dry::AutoInject(config)
# User code
MyGem.configure do |config|
setting :expected_interface, UserClass
And I have some thoughts about whether I'm using or abusing all of that. In particular:
1 - About using dry-configurable as an IoC container. I think it has some similarities: a kind-of global container where dependencies/things can be registered. The main difference being a dry-container container is best suited for registering own code while dry-configurable is best suited for users to register things to be used by a library.
2 - Accepting 1, whether it is good to use an IoC container to register simple primitives, like
primitive string setting in the example.
3 - Accepting 1 but rejecting 2, whether then I should provide my gem users with two interfaces to configure things: something like dry-configurable for primitives and something like dry-container for expected interfaces.
4 - And then about my gem internal collaborators. Accepting 1, whether if I could register them also in dry-configurable container, so, even if not generally necessary, users would have a simple way to extend or modify my gem behaviour; for example, exchanging one collaborator for another one.
I understand these questions are very open, maybe opinionated and near ontological But at least I would like to be sure not being about to do some aberration