Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Artem Malyshev
    We can add injectable objects right to the Django routing, Celery app, Py.test fixture and similar.
    The only difference - we do it by name instead of type
    But I wander, is it possible to have multiple DB subclasses in the DI process0
    I am not sure about multiple DBs
    Artem Malyshev
    Now we have FAQ section in the docs: https://dependencies.readthedocs.io/en/latest/faq.html
    Thanks! I was hoping to see this type-annotation feature. But, sadly you do not like it.
    I have some feedback and questions about your reasoning.
    1. While I still seem to understand your point here: "It hard to tell what dependencies will be resolved based on container definition. You need to look at many different things at the time: a signature of the init method, container definition, base type of each class registered in the container"
    I would love to see an example where this can be clearly visible. And I would love to see inject-by-name way to compare them. How does this sound to you?
    2! Container definition can be split into different files which make it harder to read
    But modularity is a good thing, isn't it? And how does this work with names? What is the difference? That's not clear to me at all.
    3) Typo in "I hard"
    4] That's a valid point about different subtypes, but is possible to solve. Once can use different subtypes to define what needs to be injected. Or it is possible to use a combination of type/name to solve this case
    (I had to use different bullets styles, since gitter screws up the markup)
    Artem Malyshev
    Thanks for the feedback!
    Artem Malyshev
    I hope this two slides has explanation why declarative containers has less code and clear function/object names:
    Artem Malyshev
    Also, I have plans to support type annotation, but in a different way: check that injected argument matched expected annotation
    @proofit404 that's a good idea!
    I am currently reading Hanami guide https://guides.hanamirb.org/architecture/interactors/ I have missed it for some reason, but it is great!
    Artem Malyshev
    This is a nice video about DI and IoC: https://www.youtube.com/watch?v=pV-YKZEqsQ4
    Got some inspiration from it dry-python/dependencies#64

    I'll try to implement django middlewares support in the dependencies

    Each middleware can return injector subclass.
    Next middleware can depend on attributes defined in this subclass.
    View can depend on attributes defined by all middlewares.

    Benoit Brayer
    Hi everybody, I am struggleing with dependencies injector pytest fixture...
    It seems configured correctly, I can access the fixture inside my test using the name value,
    But, my replaced (mocked with a stub) dependency is never used...
    Do you have any idea ?
    Please find my code below :
    # In conftest.py
    from dependencies import (
    from dependencies.contrib.pytest import (
    from server.implemented.process import (
    from server.tests.stubs import (
    class ProcessConfigurationStoryOnSquareFilePatched(Injector):
        """Replace download file function by a stub retrieving a local test file instead."""
        name = 'process_configuration_on_square_file'
        fixture = ProcessConfiguration
        download_file = retrieve_square_dxf_test_file_stub
        upload_file = do_nothing_stub
    Artem Malyshev
    Contribs package is deprecated: dry-python/dependencies#192
    I suggest you not to use it, it'll be removed in the nearest future.
    Benoit Brayer
    humm ok
    I am implementing something to do it either way
    Thanks for the info Arthem ;)
    Benoit Brayer
    Thanks to let function in injector it is not toooo difficult to implement it!
    I suggest you to add a deprecated warning on this page : https://dependencies.readthedocs.io/en/latest/contrib/pytest/
    Or rather, any contrib related pages of the documentation
    Chapaev Dauren
    Hi @proofit404 , can we wrap two steps in story with transaction?
    Artem Malyshev
    Hi, you can wrap implementation functions with transaction begin and transaction end. Don't write such low-level stuff in stories.
    Chapaev Dauren

    Hi @proofit404 , sorry, didn't get it fully, can you explain it in case of bookshelf project

    class BuySubscription:
        """Buy subscription for certain category."""
        # TODO: Ignore repeated subscriptions.
        @arguments("category_id", "price_id", "profile_id")
        def buy(I):
            # TODO: Create payment record here.


    class BuySubscription(Injector):
        buy_subscription = usecases.BuySubscription.buy
        load_category = repositories.load_category
        load_price = repositories.load_price
        load_profile = repositories.load_profile
        decrease_balance = repositories.decrease_balance
        current_date = django.utils.timezone.now
        create_subscription = repositories.create_subscription
        send_notifications = current.SendNotifications.send

    for example I want to wrap persist_payment and persist_subscription functions with transaction

    Artem Malyshev

    In that case, I'll keep the use case and the injector the same way they are.

    In the repositories persist_payment will start the transaction inside the function and persist_subscription will end a transaction.

    To make it more generic you can write StartTransaction and EndTransaction classes. Inject load_category and load_subscription functions.

    Yevhen Ts.
    can we inject other injector in injector ? for now i get this error _dependencies.exceptions.DependencyError: Do not instantiate Injector
    Artem Malyshev
    Could you show the source code?
    Yevhen Ts.
    class MinioInjector(Injector):
        minio = Minio(**MINIO_CONNECTION)
        minio_story = MinioStory
    class FillDataInjector(Injector):
        elastic = NewsElasticInjector
        fill_story = FillDataFromElasticStory
    class ExcelExportInjector(Injector):
        elastic = FillDataInjector
        minio = MinioInjector
        email = mail_send_export_file
        excel_story = ExportExcelStory
    class MainExportInjector(Injector):
        excel = ExcelExportInjector
        doc = Mock()
        pdf = Mock()
        log_story = ExportMainLogStory
    excel = ExcelExportInjector , this part of code have this error
    Artem Malyshev
    Sorry for the late response, could you provide complete traceback?
    Peter Zvirinsk√Ĺ

    Hi there! I came across this library a while back and I really like it. I have used it in one of my projects and it works like a charm. However, assigning classes in the Container definition is throwing mypy off (naturally, it does not know that the variable will actually become a class instance instead of the class). What is the recommended way of using dependencies with mypy? I currently use # type: ignore which is a bit painful.


    Artem Malyshev

    Hi! Thanks for reaching out!

    Indeed, dependencies behavior is way complex for mypy to figure out stuff. We had in mind to write a plugin for mypy to infer types there.

    This task turns out to be way too complex to implement. It would take unreasonable amount of time to implement.

    I decided to dedicate my time to the features of the library instead.

    If you like to write mypy plugin which will at least ignore dependencies properly, this contribution is more than welcome!

    To be honest, dependencies, stories, and mappers do a ton of work to validate things at runtime. So any mypy plugin will duplicate that work.

    Have a good day :tada:

    Best regards,

    Artem Malyshev

    These chat rooms left for historical purposes only. All active maintainers of the project have left gitter.

    Projects are still properly maintained. If you have any questions, please file an issue in our issue tracker:

    Issues are better to keep track of the community interests. It could be converted to tasks easily. It preserves the history of resolution. It's google friendly. Let's keep our conversation in a structured way! See you there.