Skip to content

Feature: Add resource type parameter to init and shutdown resources using specialized providers #858

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

Merged
merged 5 commits into from
Jun 16, 2025

Conversation

amoncusir
Copy link
Contributor

@amoncusir amoncusir commented Feb 21, 2025

Objective

Enable the initialization and shutdown of resources by specifying their type. This allows you to create logical groups of resources and handle them by type, similar to applying resource scoping.

Changes

  • New Argument: Added an optional argument to both Container.init_resources and Container.shutdown_resources to specify which resource type(s) should be processed.
  • Tests: Added tests to ensure that resource scoping works correctly, including scenarios where dependent resources belong to different types.
  • Docs: Added documentation on resource to explain how can be used

@amoncusir amoncusir marked this pull request as ready for review February 22, 2025 18:51
Copy link

@colo-o colo-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty useful!

@wadinj
Copy link

wadinj commented Apr 25, 2025

@ZipFile any changes to make this merge?

Copy link
Contributor

@ZipFile ZipFile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! Sorry for delay. I have mixed feeling about this change, since this is not a proper scoping implementation, but rather a workaround. Either way, I think we can accept it for now, since introducing real scopes would probably require some serious re-engeneering on our part.

I've left some comments to the code + we need to add support for passing provider class in the Lifespan from dependency_injector.ext.starlette.

@amoncusir
Copy link
Contributor Author

Hey! Sorry for delay. I have mixed feeling about this change, since this is not a proper scoping implementation, but rather a workaround. Either way, I think we can accept it for now, since introducing real scopes would probably require some serious re-engeneering on our part.

I've left some comments to the code + we need to add support for passing provider class in the Lifespan from dependency_injector.ext.starlette.

Yep! Exactly, it's a workaround. When I started with this, my first approach was to refact the current Resource class, but as you said, requieres a serious re-engeneering and this small change just do the work and provide a way to init indpendenent resources.

@ZipFile ZipFile changed the base branch from master to develop June 3, 2025 12:01
cursor-com[bot]

This comment was marked as outdated.

…sources` methods to provide a more granular way to initialize the desired resources and add the possibility to scope that ones.
…nd shutdown_resources using the resource_type argument and how can scope the resources
@ZipFile ZipFile force-pushed the feat/specifit_resource_type branch from 948a762 to cde7eaf Compare June 16, 2025 08:19
cursor-com[bot]

This comment was marked as outdated.

@coveralls
Copy link

coveralls commented Jun 16, 2025

Coverage Status

coverage: 94.59% (+0.006%) from 94.584%
when pulling 4604341 on amoncusir:feat/specifit_resource_type
into b411807 on ets-labs:develop.

@ZipFile ZipFile force-pushed the feat/specifit_resource_type branch from cde7eaf to 4604341 Compare June 16, 2025 08:27
Copy link

@cursor-com cursor-com bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Invalid Resource Type Causes Incorrect Error

The init_resources and shutdown_resources methods raise a generic TypeError ("issubclass() arg 1 must be a class") when the resource_type parameter is a non-class value (e.g., None, string, number). This occurs because the issubclass() check is performed directly on the input without first validating if resource_type is a class, leading to inconsistent error messages compared to the intended custom TypeError.

src/dependency_injector/containers.pyx#L320-L322

if not issubclass(resource_type, providers.Resource):
raise TypeError("resource_type must be a subclass of Resource provider")

Fix in Cursor


Was this report helpful? Give feedback by reacting with 👍 or 👎

@ZipFile ZipFile merged commit 4bfe645 into ets-labs:develop Jun 16, 2025
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants