Skip to content
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

Configuration object is a dictionary and not an object with which the dot notation could be used to access its elements #814

Open
Zevrap-81 opened this issue Sep 2, 2024 · 2 comments

Comments

@Zevrap-81
Copy link

I cannot figure out why the config is a dictionary, while in every example it is an object with "." (dot) operator to access its variables.

Here is a simple code that I used:

from dependency_injector import containers, providers
from dependency_injector.wiring import Provide, inject


class Container(containers.DeclarativeContainer):
    config = providers.Configuration()


@inject
def use_config(config: providers.Configuration = Provide[Container.config]):
    print(type(config))
    print(config)



if __name__ == "__main__":
    container = Container()
    container.config.from_yaml("config.yaml")
    container.wire(modules=[__name__])

    use_config()

and the type is a 'dict'

@daewon
Copy link

daewon commented Sep 13, 2024

I'm experiencing the same problem.

@Aesonus
Copy link

Aesonus commented Jan 4, 2025

Yes, the injected config is supposed to be a dict type. Dot notation can be used in the Declarative container and in the Provide notation, but not after the config has been injected, it will return the type of object at the key specified or a dict if the whole config is injected.

For example, if you need to inject a certain key, from the config, that can be done like this:

# ...
@inject
def use_config(config: providers.Configuration = Provide[Container.config.key]):
    print(type(config))
    print(config)
#...

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

No branches or pull requests

3 participants