Skip to content

How to fail application if dependency cannot be wired? #538

@gtors

Description

@gtors

For example, developer make typo in Provide[...]:

container.py

class ApplicationContainer(containers.DeclarativeContainer):
    some_service = providers.Singleton(object)

app.py

# FastAPI

@app.get("/")
@inject
async def some_handler(service = Depends(Provide["sOme_service"])):  # suppose there is a typo in the name of the container attribute
    # `service` will be <dependency_injector.wiring.Provide object at 0x7f59daf8c580>
    pass

I've tried this approach, but it doesn't work for the Singleton:

Provide["some_service", required()]  # AttributeError: 'dependency_injector.providers.Singleton' object has no attribute 'required'

So, how to crash app in case if dependency cannot be resolved?

Activity

gtors

gtors commented on Dec 14, 2021

@gtors
Author

Why not raise an exception here?

if provider is None:
continue

tarohi24

tarohi24 commented on Dec 31, 2021

@tarohi24

+1 It would be great to have an option to raise an exception when failing to resolve a dependency.

JanPalasek

JanPalasek commented on Jan 30, 2022

@JanPalasek

Does this work for modules not mentioned in wire function? Mb implement into inject decorator?

self-assigned this
on Jan 31, 2022
jeffmace

jeffmace commented on Sep 2, 2022

@jeffmace

I'm getting started with python-dependency-injector and have been tripped up by some self-imposed wiring errors. The end result is that my methods get called with Provide object when I would prefer an Exception explaining the issue.

My issues have fallen into two buckets:

  1. Improper string identifiers passed into Provide. I have a fix for this which replaces

return self._resolve_string_id(provider, modifier)

resolved = self._resolve_string_id(provider, modifier)

if resolved is None:
    raise KeyError(f"Unable to resolve a Provider for '{provider}'")

return resolved
  1. The other errors appear when a Container has not been wired for the Provider. This could be that no containers have been wired or that the wrong type has been wired. I believe the solution is to update _get_sync_patched so it compares patched.reference_[injections|closing] with patched.[injections|closing] to detect missing values. The Modifier could be overloaded to handle these cases so the functionality is opt-in and doesn't change the interface. If that is not desired, another parameter could be added to _Marker which indicates the desired behavior.

I can submit a PR for the first case, and take a look at implementing the second. But I wanted to get some input on the approach before beginning. I realize these issues are bugs in my application and not the library, but these changes would make debugging the issues easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @jeffmace@rmk135@tarohi24@gtors@JanPalasek

      Issue actions

        How to fail application if dependency cannot be wired? · Issue #538 · ets-labs/python-dependency-injector