Migrating from 1.* to 2.*¶
How to Read This Guide¶
This guide is intended to help you migrate existing functionality from that-depends version 1.* to 2.*.
The goal is to enable you to migrate as quickly as possible while making only the minimal necessary changes to your codebase.
If you want to learn more about the new features introduced in 2.*, please refer to the documentation and the release notes.
Deprecated or Removed Features¶
BaseContainer.init_async_resources() removed¶
The method BaseContainer.init_async_resources() has been removed. Use BaseContainer.init_resources() instead.
Example:
If you are using containers, your setup might look like this:
from that_depends import BaseContainer
class MyContainer(BaseContainer):
# Define your providers here
...
that_depends.providers.AsyncResource removed¶
The AsyncResource class has been removed. Use providers.Resource instead.
Example:
Replace all instances of:
BaseContainer and its subclasses are no longer dynamic.¶
In 1.*, you could define a container class and add providers to it dynamically. This feature has been removed in 2.*. You must now define all providers in the container class itself.
Example:
In 1.*, you could define a container and then dynamically set providers:
from that_depends import BaseContainer
class MyContainer(BaseContainer):
pass
MyContainer.my_provider = providers.Resource(some_function)
2.*, this will raise an AttributeError. Instead, define the provider directly in the container class:
Changes in the API¶
container_context() now requires a keyword argument for initial Context¶
Previously, a global context could be initialized by passing a dictionary to the container_context() context manager:
my_global_context = {"some_key": "some_value"}
async with container_context(my_global_context):
assert fetch_context_item("some_key") == "some_value"
In 2.*, use the global_context keyword argument instead:
my_global_context = {"some_key": "some_value"}
async with container_context(global_context=my_global_context):
assert fetch_context_item("some_key") == "some_value"
Context reset behavior changed in container_context()¶
Previously, calling container_context(my_global_context) would:
- Set the global context to
my_global_context, allowing values to be resolved usingfetch_context_item(). This behavior remains the same. - Reset the context for all
providers.ContextResourceinstances globally. This behavior has changed.
In 2.*, if you want to reset the context for all resources in addition to setting a global context, you need to use the reset_all_containers=True argument:
async with container_context(global_context=my_global_context, reset_all_containers=True):
assert fetch_context_item("some_key") == "some_value"
Note:
reset_all_containers=Trueonly reinitializes the context forContextResourceinstances defined within containers (i.e., classes inheriting fromBaseContainer). If you also need to reset contexts for resources defined outside containers, you must handle these explicitly. See the ContextResource documentation for more details.
Additionally, calling container_context() without any arguments will no longer reset the global_context, if you want to drop the global_context set preserve_global_context=False:
async with container_context(preserve_global_context=False):
fetch_context_item("key") # None (the default value)
Container classes now require you to define default_scope¶
In 2.*, you must define the default_scope attribute in your container classes if you plan to define any ContextResource providers in that class. This attribute specifies the default scope for all ContextResource providers defined within the container.
Example:
from that_depends import BaseContainer, providers
class MyContainer(BaseContainer):
default_scope = None # This will maintain compatibility with 1.*
p = providers.ContextResource(my_resource)
default_context = None maintains the same behaviours as in 1.*. Please look at the scopes Documentation.
Potential Issues with container_context()¶
If you have migrated the functionality as described above but still experience issues managing context resources, it might be due to improperly initializing resources when entering container_context().
Here’s an example of an incompatibility with 1.*:
from that_depends import container_context
async def some_async_function():
# Enter a new context but import `MyContainer` later
async with container_context():
from some_other_module import MyContainer
# Attempt to resolve a `ContextResource` resource
my_resource = await MyContainer.my_context_resource.async_resolve() # ❌ Error!
To resolve such issues in 2.*, consider the following suggestions:
Pass explicit arguments to DIContextMiddleware¶
If you are using DIContextMiddleware with your ASGI application, you can now pass additional arguments.
Example with FastAPI:
import fastapi
from that_depends.providers import DIContextMiddleware, ContextResource
from that_depends import BaseContainer
MyContainer: BaseContainer
my_context_resource_provider: ContextResource
my_app: fastapi.FastAPI
my_app.add_middleware(DIContextMiddleware, MyContainer, my_context_resource_provider)
This middleware will automatically initialize the context for the provided resources when an endpoint is called.
Avoid entering container_context() without arguments¶
Pass all resources supporting context initialization (e.g., providers.ContextResource instances and BaseContainer subclasses) explicitly.
Example:
from that_depends import container_context
MyContainer: BaseContainer
my_context_resource_provider: ContextResource
async with container_context(MyContainer, my_context_resource_provider):
# Resolve resources
my_container_instance = MyContainer.my_context_resource.sync_resolve()
my_provider_instance = my_context_resource_provider.sync_resolve()
Explicit initialization of container context is recommended to prevent unexpected behavior and improve performance.
Further Help¶
If you continue to experience issues during migration, consider creating a discussion or opening an issue.