-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
defer type annotation analysis #234
Comments
note this is not a pressing issue, i found a way to resolve this by moving a provider class to a especially ugly place and lazy importing it when making the root container |
You can try registering classes in provider instance instead of class-based approach with decorators |
the providers are actual type-annotated functions, so i'd like to avoid pulling things apart even more |
I mean instead of this: class MyProvider(Provider):
@provide
def create_x(self, dep: Y) -> X: ... # immediate resolving You can do this: def create_x(dep: "Y") -> "X": ...
..
from x import X
from y import Y
provider = Provider()
provider.provide(create_x) But from my side it looks like a problem with your code structure. Try splitting providers into more parts. Just in case something is missed: your providers do not need to know about each other and who produces what, they are wired only inside container. |
If evaluating the type annotations was deferred until wireing time I wouldn't see any issues I'm in the process of resolving historical grown recursive dependencies, I'm happy to provide an implementation that retains eagerness but makes wire time available but import time unavailable types a warning instead of a error as it's not always easy to quick detangle |
im currently migrating a codebase with quite some import cycles to dishka to resolve this,
unfortunately i frequently see errors like
The text was updated successfully, but these errors were encountered: