Feature Request: Override registered Dependencies

[AMCON-Gerst]

Hello,
we sometimes need different dependencies depending on the configuration of our software. But since we need normally the default of the dependencies, I want a way to overwrite dependencies.

I've made an example implementation of this extension already in our fork: https://github.com/AMCON-GmbH/ferrunix/tree/feature/override_registration
Due to the contributing guidelines, however, larger proposals should first be discussed in the issue.

My suggestion is to configure this as a separate feature. This can be discussed because there are no extra dependencies to this crate for the "override" functions.

Please give me feedback on whether the idea is basically desirable.
I would then add further test cases and create a pull request.

[Leandros]

Could overwriting of dependencies be achieved with sub-registries (#6)?

Essentially, the registries would behave like an inheritance tree. Each sub-registry may have their own types registered, which would overwrite the ones from the inherited/parent registry, and they may exist in parallel (allowing for multiple trees of registries, and greater flexibility).

             ┌───────────────┐              
             │ Root Registry │              
             └───▲───▲───────┘              
                 │   │                      
        ┌────────┘   └────────┐             
┌───────┴──────┐      ┌───────┴──────┐      
│ Sub-Registry │      │ Sub Registry │      
└──────────────┘      └──▲────▲──────┘      
                         │    │             
               ┌─────────┘    └─────┐       
       ┌───────┴──────┐     ┌───────┼──────┐
       │ Sub Registry │     │ Sub Registry │
       └──────────────┘     └──────────────┘

If a type is requested from one of the sub-registries, and it's not found, it would delegate to it's parent registry, until eventually the root registry is reached (and an error is returned, if the registered type isn't found).

[AMCON-Gerst]

The definition of a sub-registry could help to solve our problem.

If I understand the concept correctly, the global registry would be the root registry, and the sub-registry would then define the configuration parameter overrides.

With this concept, we would solve our problem, which I wanted to solve with the override feature.

Do you have a schedule for the feature? I'll have to see if I can otherwise contribute the feature as a pull request if it's too far in the future.

[Leandros]

We haven't needed this yet. I'll take a today at what it would take and give you a rough timeline.

[Leandros]

@AMCON-Gerst, because the changes required to make to make child registries work needed to modify the return types of the entry points, I did a bunch of breaking changes in one go. These changes are in the wip-0.5.0 branch.

The changes you're most interested in is the child registries addition in this commit: d6a5944

Let me know if these changes would work for you.

[AMCON-Gerst]

@Leandros, thank you for your work on the feature. At first glance, it looks good.
In the meantime, we had to move on, so we have currently continued with another crate in the implementation, even if it does not fit so well. If we find further problems with the other crate, we will be happy to come back to this one.