Dependency injection framework is constructing the object first and then injecting the dependency which is incorrect

[Nachiappan]

Dependency injection framework is constructing the object first and then injecting the dependency which is incorrect.

def requires(*dependencies):
    """Inject specified dependencies from the registry into the instance."""
    def wrapper(self, *args, **kwargs):
        """Inject each dependency from the registry."""
        self.__wrapped_init__(*args, **kwargs) ----------------------> Constructs object First

        for dependency in self._dependencies: ----------------------> Inject dependency Second
            if dependency not in REGISTRY:
                raise UnresolvableDependencyException(dependency)
            setattr(self, dependency, REGISTRY[dependency])

It would be better to inject the dependency first and then construct the object, so that the dependency is available during object construction.

[Adam Young (ayoung)]

Is there a DI framework for Python that does this cleanly?

[David Stanek (dstanek)]

I wrote a DI framework for Python called snake-guice that could replace this implementation. I would be pretty the existing requires and provides functions to use the snake-guice implementation. This gives you a doorway to the more advanced features.

[Dolph Mathews (dolph)]

I'd be happy to see the DI implementation replaced with something better - It was mostly implemented to achieve a refactor.

[Dolph Mathews (dolph)]

Unassigning due to inactivity.

[Alexey Miroshkin (amirosh)]

The current DI implementation is very loosely coupled. Provider is registered when it is constructed somewhere, without providing any prior information. Technically we can't guarantee that a dependency will be injected before a consumer object construction, because a provider object could be instantiated later on. Moreover this problem is not applicable just to __init__ method, a consumer object is inconsistent state from a developer point of view and any methods which rely on injected attribute are vulnerable.

I see the following options:

1. I quickly implemented the injection before init by delaying init execution until all dependencies are satisfied. It works except the case of circular dependencies, but it breaks Python object construction protocol and leave an object in inconsistent state for some time. So in general there is no difference with the current situation or even make it worse. Moreover the case of circular dependencies is very problematic.

2. Add a callback method to the consumer, like _dependencies_injected and invoke it, if a particular consumer object has it, when all required dependencies are injected. Not so elegant as satisfy all dependencies before init, but gives a developer a right amount of control over an object state.

3. Make a framework more rigid, by registering providers as part of configuration step - for example like Guice module. It may require more changes but would give us a clear understanding of the object graph.

I'm sending a patch wich implements the second approach but let's discuss other options.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/117523

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alexey Miroshkin (<email address hidden>) on branch: master
Review: https://review.openstack.org/117523
Reason: Doesn't make sense anymore

[Morgan Fainberg (mdrnstm)]

Moved to "wishlist" as this is a nice to have but it's not critical path at this point.

[Steve Martinelli (stevemar)]

Automatically unassigning due to inactivity.

[David Stanek (dstanek)]

I still have a handful of patches that I am working on for this.

[Lance Bragstad (lbragstad)]

Automatically unassigning due to inactivity.

[Morgan Fainberg (mdrnstm)]

Dependency Injection was removed/reworked. This is no longer an issue.